Proposal for a first bug day:

Date: 3. 8. (Friday) or 5. 8. (Sunday)
Product to triage: Gwenview
Domain experts to ask if they are available: @ngraham, @rkflx, @muhlenpfordt and @huoni

I'd be available from ~9:00 until 16:00 UTC on both days, but it'd be great if others could cover the rest of the time slots. Please write a comment if you'd like to participate and when you'd be available. If at least two people are joining in, I'll also communicate with the Promo team on how we can reach out to other users (reddit, Dot article, Twitter etc.).

I may be available on Sunday.

Pinging @cfeck since he does lots of bug work

Thanks for the initiative, Julian.

To assess how bug triaging could impact Gwenview's bugs, I just clicked randomly on 20 Gwenview bugs:

1. 9 bugs were valid bugs or wishes. In need of patches, and more often than not further refinement of the idea to make them a good fit for Gwenview required.
2. 7 bugs needed further investigation how Gwenview is working today in that situation or the reporter has a weird local setup. Good fit for triaging.
3. 4 bugs contained a request which might seem valid (often wanting to add stuff), but does not fit the current vision of Gwenview (of not adding everything, since it is different from DigiKam). Would need someone to say no, but not someone to post "awesome idea" resulting in disappointment when a patch gets turned down later.

This query results in 397 bugs found. It's probably counterproductive to flood Gwenview's small team with requests relating to advice for bugs fitting case #3 (it often takes quite some thinking to figure out if those wishes are something we want or not). Would it make sense to compile a list of bugs belonging to case #2, which are a better fit for triaging?

developers mainly have good, high-quality bug reports left

Of course I can only speak for me, but after looking through most of Gwenview's bugs last year for triaging and getting an overview, these days I visit Bugzilla mostly to triage new bugs. What I do in terms of fixes or features is mostly determined in other ways, and likely won't be affected by any potential triaging (other than that the triaging takes away hacking time ;).

We strive to attract as many new contributors as possible

In my experience, most small paperclip bugs for Gwenview (of which there are many, and which are a better fit to attract new contributors than old left-over wishes from the last ten years of Gwenview) are not even on Bugzilla.

Some time ago I posted some of them as junior jobs, which promptly resulted in fixes and new faces showing up. This was quite surprising and massively strained reviewing capacities. These days I take it slower, to ensure having time to actually mentor newcomers with the attention they need and deserve.

That said, I'll see what I can do to help…

In T9250#152469, @rkflx wrote:

Thanks for the initiative, Julian.

To assess how bug triaging could impact Gwenview's bugs, I just clicked randomly on 20 Gwenview bugs:

1. 9 bugs were valid bugs or wishes. In need of patches, and more often than not further refinement of the idea to make them a good fit for Gwenview required.
2. 7 bugs needed further investigation how Gwenview is working today in that situation or the reporter has a weird local setup. Good fit for triaging.
3. 4 bugs contained a request which might seem valid (often wanting to add stuff), but does not fit the current vision of Gwenview (of not adding everything, since it is different from DigiKam). Would need someone to say no, but not someone to post "awesome idea" resulting in disappointment when a patch gets turned down later.
   
   This query results in 397 bugs found. It's probably counterproductive to flood Gwenview's small team with requests relating to advice for bugs fitting case #3 (it often takes quite some thinking to figure out if those wishes are something we want or not). Would it make sense to compile a list of bugs belonging to case #2, which are a better fit for triaging?

Thanks for your detailed report regarding bugs for Gwenview. I picked this product more or less at random: I've already triaged ~500 bugs for Dolphin recently so I'm a bit exhausted when it comes to Dolphin bugs and I wanted to propose an application that is relatively common. After your research it'd be better to pick another program, but I am not sure which choice would work out well. Do you have an idea for an alternative?

developers mainly have good, high-quality bug reports left

Of course I can only speak for me, but after looking through most of Gwenview's bugs last year for triaging and getting an overview, these days I visit Bugzilla mostly to triage new bugs. What I do in terms of fixes or features is mostly determined in other ways, and likely won't be affected by any potential triaging (other than that the triaging takes away hacking time ;).

I am aware that the triaging might not be directly helping with any priorities, but I still consider it valuable from a developer's standpoint. This is my motivation behind triaging in general: If somebody reports a bug and never gets a response this drastically lowers the chance that they'll report another bug or get involved with KDE in an other way. A response, even if only made after multiple years, helps to bridge the gap between developers/triagers and casual users.

Some time ago I posted some of them as junior jobs, which promptly resulted in fixes and new faces showing up. This was quite surprising and massively strained reviewing capacities. These days I take it slower, to ensure having time to actually mentor newcomers with the attention they need and deserve.

Ah, I think I actually saw that post, didn't know that this flooded Gwenview so much... We should learn from that experience so that capacity problems don't happen again with other KDE projects.

That said, I'll see what I can do to help…

Great, I am sure that you'd have a lot of other things to do (also non-KDE related) which would be equally or more important so I really appreciate your detailed response.

In T9250#152470, @xyquadrat wrote:

After your research it'd be better to pick another program, but I am not sure which choice would work out well. Do you have an idea for an alternative?

Some bugs are certainly worth triaging in Gwenview, I did not want to discourage you ;) Maybe we can start on a smaller scale, and then try to ramp up to bigger audiences? Something like a test run, before having a big plan fail on the first try?

You could look at some numbers on Bugzilla, both in the overall number of bugs and how they add up over time. I'd say those components which have bugs piling up rapidly, and which are important to the success of the project are worth looking at most.

Documenting bugs is not a goal in itself, fixing them is. In the end it comes down to how exciting a component is to work on for current and future contributors. For example, do we want good searching capabilities? If so, is Baloo the way to go, or a different technology? If it is Baloo, are there people actively working on it, or is there at least the potential to get people working on it if the bugs were organized a bit better? If yes, then it might make sense to triage Baloo.

Same thinking for kioslaves/NFS/remote storage, which seems like a topic which comes up from time to time. Ask Nate for more.

Apart from those strategic angles, you could simply ask on kde-devel if there is any project interested, perhaps people will queue up for the service you are offering ? ;)

I am aware that the triaging might not be directly helping with any priorities, but I still consider it valuable from a developer's standpoint. This is my motivation behind triaging in general: If somebody reports a bug and never gets a response this drastically lowers the chance that they'll report another bug or get involved with KDE in an other way. A response, even if only made after multiple years, helps to bridge the gap between developers/triagers and casual users.

That's very true, and that's why we make sure to respond to almost every current bug activity (either for a new bug or for a new comment on an old bug) in Gwenview. This often resulted in fixes getting contributed, actually! Hoping to gain contributors from very old bugs where there is no activity at all is not worthless, but probably not the most efficient use of resources.

IOW, make sure to help cover current bug activity (@cfeck knows more), and do bug triaging in a way to support that. For example if there are too many duplicates and outdated bugs in a component, reporting or triaging new bugs is more difficult than necessary. Determine those areas by asking triagers or looking at numbers, then pick a topic for cleanup.

Anyway, you should probably stop overthinking (like I'm doing…) and just start somewhere…

Gwenview's bugs are already fairly well triaged these days. I would recommend going through the old kio bugs. I think this will yield more fruit since there's lot of crusty stuff in there that's already been fixed over the years or is no longer relevant, and the work will have a real benefit since it will bring us closer to being able to have 0 bugs in kio with everything in the new frameworks-kio and kio-extras components instead. At that point, we can go through those bugs. KIO is super important since it underpins the operation of many KDE apps and features.

If you want to do an app, KMail looks like it's in need of a good bug triage, but alas I wouldn't be able to help since I don't use KMail. Konsole is another good option.

In T9250#152472, @ngraham wrote:

Gwenview's bugs are already fairly well triaged these days. I would recommend going through the old kio bugs. I think this will yield more fruit since there's lot of crusty stuff in there that's already been fixed over the years or is no longer relevant, and the work will have a real benefit since it will bring us closer to being able to have 0 bugs in kio with everything in the new frameworks-kio and kio-extras components instead. At that point, we can go through those bugs. KIO is super important since it underpins the operation of many KDE apps and features.

I've also thought about kio and it'd be great if we could finally close down the old kio product completely. My main concern was that not everybody does have the setup to reproduce those bugs (missing samba share or no floppy disks available). If we can divide the bugs in a way such that everybody can actually triage his bugs, I'm all for it.

Konsole is another good option.

Yes, we should keep Konsole as an option as well (maybe for another bug day if we go with kio for a first one).

@rkflx, thanks for all your input and suggestions. I'll try to keep them in mind for my future bug triaging endeavors.

Okay, I further investigated the suggestion from @ngraham and tried to come up with a list of subproducts for kio which can be triaged by pretty much everybody with a computer. Here are the subproducts that I think are a good fit for a bug triaging day:

• info:/ (5 bugs)
• tar:/ (10 bugs)
• help:/ (3 bugs)
• camera:/ (34 bugs)

-> 52 bugs in total

I also considered the ssl slave, but this one appears to be KDE4-only so I excluded it for now. With 52 bugs an obvious good number of triagers would be five, which would also fit the small scale test that was proposed by @rkflx. Now, who is joining in? If we do not get five people from this task here I'll consider setting up a reddit post or a tweet together with the promo team so that we are able to process all the bugs from those products if possible.

I'm game! :)

I'm interested :)

Okay, I'm really sorry for my late announcement: We are going to do a bug triaging day tomorrow, Sunday the 5th. @ngraham and @nicolasfella have already mentioned that they'll participate, but if anybody else would like to join in, please do so! I'll be online on the #kde-bugs channel for most of my day (so from ~9:00 UTC till 19:00 UTC).

I portioned the list into batches of 10 bugs. If you want to take one, then leave a comment here so that we do not triage the same batch twice :).

1. Batch: All tar bugs (https://bugs.kde.org/buglist.cgi?component=tar&list_id=1534760&product=kio&resolution=---) - @xyquadrat
2. Batch: All help and info bugs (https://bugs.kde.org/buglist.cgi?component=info&list_id=1534759&product=kio&resolution=---, https://bugs.kde.org/buglist.cgi?component=help&list_id=1534761&product=kio&resolution=---)
3. Batch: Oldest kamera bugs (https://bugs.kde.org/buglist.cgi?chfieldfrom=2000-01-01&chfieldto=2009-08-10&component=kamera&list_id=1534763&product=kio&query_format=advanced&resolution=---)
4. Batch: Still old kamera bugs (https://bugs.kde.org/buglist.cgi?chfieldfrom=2009-08-10&chfieldto=2013-07-01&component=kamera&list_id=1534765&product=kio&query_format=advanced&resolution=---)
5. Batch: New kamera bugs, 14 bugs instead of 10 (https://bugs.kde.org/buglist.cgi?chfieldfrom=2013-07-01&chfieldto=2018-08-01&component=kamera&list_id=1534766&product=kio&query_format=advanced&resolution=---)

I'll do my best, but it turns out that tomorrow is going to be a busy family day for me, so I may not get as much done as I'd otherwise expect to.

In T9250#153580, @xyquadrat wrote:

3. Batch: Oldest kamera bugs (https://bugs.kde.org/buglist.cgi?chfieldfrom=2000-01-01&chfieldto=2009-08-10&component=kamera&list_id=1534763&product=kio&query_format=advanced&resolution=---)
4. Batch: Still old kamera bugs (https://bugs.kde.org/buglist.cgi?chfieldfrom=2009-08-10&chfieldto=2013-07-01&component=kamera&list_id=1534765&product=kio&query_format=advanced&resolution=---)

Done.

(But please advise which frameworks bug component to move the bugs which are still open to.)

Thank you @rkflx for your work. The situation is indeed a bit confusing, I think that most old kio bugs either belong to frameworks-kio (if they are related to Dolphin/Gwenview parts) or kio-extras (for the rest), but there are some exceptions...

According to the nice weekly summary (https://bugs.kde.org/weekly-bug-summary.cgi?tops=50&days=7), we managed to close 23 bugs with a few more to come as the status of those bugs is currently unclear. That also means that kio is finally no longer in the top 30 of all products, so everybody involved is surely doing great work cleaning up! I am planning to do another bug day later this month or in early September, but I'll comment here soon™ with more information & things that I need to improve regarding organization. Currently I am thinking about focusing on Krita, but we'll have to see if that works out or not.

Hi @xyquadrat I've had @sysadmin recreate the Bugsquad, but in Phabricator for easy collaboration. I'd like to resurrect it, with a set schedule of triaging days as you started here. I've asked @sysadmin about adding a calendar to the project, or allowing other Calendar edit access. If not, I'll create a Google Calendar people can subscribe to I suppose.

I'm in process of helping Nate and group clean up Bugzilla in T6832, to make this future triaging easier. If you're interested in resurrecting the Bugsquad, please feel free to join it as a member. Same goes for anyone else on this Task.

Please don't add Sysadmin to multiple tasks which raise the same issue as this generates duplication.
The Calendar has been sorted out as I commented on the other task.