Thanks to all the participants of the first BugWeek session!!

I propose to use this topic to discuss the overall conclusions of the whole experience. I would like to get feedback about this questions:

• Did you enjoy participating on the BugWeek session and working with bug reports? (I hope so )
• Would you change some step of the workflow ?
• Do you think that a whole week of preparation is really needed ?
• Would you like working with more(or less) bug reports ?
• If you had questions, were you able to get an answer? Were those answers useful to you ?
• Would you like to have more mentors ?
• Would you like to start working on bug reports on your own ?
• Would you like more information/guides/tutorials about bug triaging ?
• Would you change something else ?

Personally, I think the overall experience was great, even if there are some details to polish. I'm glad to see newcomers (and people that I already knew) being interested and working together (even on small teams!)

See you in the next BugWeek! (you can always find me at #kde-bugs on IRC; or even in this forum)

Hi!

Did you enjoyed the work ? (I hope so )

Yep, far more than expected !

Would you change some step of the workflow ?

Nope. It was fine to me.

Do you think that a whole week of preparation is really needed ?

If someone wanted to set up a trunk-based environment for the first time, for test purpose I guess one week could be necessary. Building KDE is always an adventure in the first times )

Would you like working with more(or less) bug reports ?

Well it seems it was fine enough since we didn't manage to check it all. But it's better to have too much, like this, so that everybody can work on a part and not duplicate the efforts on the same stuff.

If you had questions, were you able to get an answer? Were that answers useful to you ?

Yes, it was easy to get answers, especially on IRC on #kde-bugs

Would you like to have more mentors ?

I felt like all the #kde-bugs staff was mentoring us

Would you like to start working on bug reports on your own ?

Yes definitely.

Would you like more information/guides/tutorial about bug triaging ?

I think the guidelines you gave in the first post were really perfect. Quite detailed, but flexible, exactly what is needed for beginners. If they are not written elsewhere these guidelines should be written down in the wiki too. It will be a reference for me now.

What will be necessary is ponctual advices, that we can get on the forum or on IRC.

Would you change something else ?

IMO it went like a charm, so no.

What is really interesting me now is how this will end. For example how do you handle bugs that can't be reproduced anymore with more recent versions of KDE than the reporter? Is it enough to close the report?
I'm very curious to know how such decision happen.

Also how are decisions made when people disagree on a bug? (aka "it's not a bug it's a feature"). That's "socially" interesting

Finally I have to thank you and all the people who organized this, because it went really smoothly and you gave a good methodology for bug triaging. I think KDE will really benefit this!

Best regards,

--
Kolia

Dario_Andres wrote:[*]Did you enjoy participating on the BugWeek session and working with bug reports? (I hope so )

I enjoyed the experience, bug triaging can be fun.

Dario_Andres wrote:[*]Would you change some step of the workflow ?

I think there needs to be some (better) way for people to drop bugs out of their batch: the problem this time seemed to be the bugs that required multiple monitors to test.

Dario_Andres wrote:Did you enjoy participating on the BugWeek session and working with bug reports? (I hope so )

Yes, it gives me the feeling to do something usefull with my free time.

Dario_Andres wrote:Would you change some step of the workflow ?

Nope.

Dario_Andres wrote:Do you think that a whole week of preparation is really needed ?

As I used my stable environment, I would say one week is too much. However, as mentioned by Kolia, if you compile a KDE especially for that, one week may be necessary at the beginning.

Dario_Andres wrote:Would you like working with more(or less) bug reports ?

I think batches of 10 were good. For the fastest, they could take a second or a third one if they wanted.

Dario_Andres wrote:If you had questions, were you able to get an answer? Were those answers useful to you ?

Absolutely, people on the IRC channel are always present to help us, and answer our questions.

Dario_Andres wrote:Would you like to have more mentors ?

No, I already feel like I get help when I need.

Dario_Andres wrote:Would you like to start working on bug reports on your own ?

I already do

Dario_Andres wrote:Would you like more information/guides/tutorials about bug triaging ?

Like Kalio, I would like a bit more information about tagging the reports. For instance, I think I would be/am to fast on marking them as RESOLVED. I would like to see how you will proceed with the reports we just checked.

Dario_Andres wrote:[*]Would you change something else ?[/list]

Nope, was great. Go job guys, thank you

I just thought of something. All the bug reports we handled during this session were "normal" ones.

How do you handle crash ones? They are almost never reproducable AFAICS. Also, is there special output/trace to ask?

Kolia wrote:What is really interesting me now is how this will end. For example how do you handle bugs that can't be reproduced anymore with more recent versions of KDE than the reporter? Is it enough to close the report?
I'm very curious to know how such decision happen.

Bugs that can't be reproduced anymore should be double checked and closed as RESOLVED/WORKSFORME or RESOLVED/FIXED (if the reporter can confirm that the issue was properly fixed)
In the meantime, the reporter could update the KDE SC version he/she is using and confirm if the issue is solved.

Kolia wrote:Also how are decisions made when people disagree on a bug? (aka "it's not a bug it's a feature"). That's "socially" interesting

This is most of the times forwarded to the developers directly as they have to "judge it"

ComputerDruid wrote:I think there needs to be some (better) way for people to drop bugs out of their batch: the problem this time seemed to be the bugs that required multiple monitors to test.

Yes, we need to improve the batches system to avoid conflicts and to allow a smarter bug distribution.

Kolia wrote:I just thought of something. All the bug reports we handled during this session were "normal" ones.

How do you handle crash ones? They are almost never reproducable AFAICS. Also, is there special output/trace to ask?

Indeed, I didn't include crash reports in the batches as they are a bit different to handle.
Checking duplicates of crash reports involve comparing backtraces (that is a bit advanced) besides comparing the situation.
I need to reask the user to repeat the situation to check if the application crashes again, in order to get steps to reproduce.

---

Thanks everyone for all your feedback