As I said in a blog post, I would like to join efforts with the Klassroom/Kourses initiative to boost the bugdays workflow and to bring more new contributors to help us to check the bug reports at bugs.kde.org

As I don't really know if the two workflows could be "compatible", I will summarize a day of work in a BugDay:

1) We have all the information in the techbase (the main bugday page and several other article explaining the workflow and some tips/hints)
2) Interested users read the explanations (we are also on #kde-bugs to give more detailed explanations if needed)
3) The user "signs in", adding his/her name in the list and their KDE and Qt version.
4) The user chooses a batch of bug reports (10 reports) to work on:
He/She has to check for missing details, reproducibility, possible duplicates, if it is fixed already, and so on.
5) When the user finishes with a bug report (and as new users do not have bugzilla permissions), he/she adds the bug report number + some explanation in one of the categories below (ex. "To be marked as duplicate", "To be marked as fixed", "Needs more information", "I don't know", "A developer needs to check this", and so on)
6) When the user finishes a batch, she/he can go back to step 4 (if they want to...)

At the end of the day (or the weekend), and during the next week we evaluate the results of the bugday. We try to determine which people identified the bug reports properly and encourage them to join us. They may eventually gain permissions to work on their own.

We also let newbie triagers with permissions to close the bug reports according to the category status (so they will have some credit of their work, and will be encouraged to keep helping us)

---

That's it: the big question is:
- Do you think that the Kourses initiative will be useful to improve this workflow and bring more people to work with us? Do you think in any other alternative workflow ?

I have to mention that editing wikipedia tables on the techbase articles can be unfriendly some times, and there could be conflicts if two people edit the same article's section at the same time. - Do you think a "forum approach" could help us to improve this situation ?
It could also have some other drawback, but we could evaluate and discuss it

BugDay page example: http://techbase.kde.org/Contribute/Bugs ... PlasmaDay1

---

Thanks in advance for your feedback!!
Regards

Great Idea!

What is important for the klassrooms to work though, we need the material that is being worked out here on the forum. So every possible follower can read it and maybe get some valuable insight. Thas is basically the sense of the klassrooms here on the forum: have something archived that everybody can read.

But apart from that, i would like to see that coming!

Thanks for the consideration

I was thinking: may be we could have a subsection on the Kourses subforum named "BugDay" .. in that section we could have some stick-ed articles explaining the workflow and some tips and hints (or may be pointing to the techbase articles)

Then, for each real bugday we could have a forum post, in which:

In the first post:
- We describe the topic/application of that bugday
- We encourage the user to read the explanations and to join us
- We put the batches URL

Then, every interested people could add a post saying
"I sign up/register. I'm using KDE SC x, Qt y, other settings."
"I will pick batch number Z"
(we could later striketrought that batch in the main post)

--

The problem is how to organize the categories for every bug report "result".
Some ideas:

Every user could modify its own post (the one which says the KDE version) and add the bug number with the description and a status.
Example: "bug XXXXXX is probably a duplicate of bug YYYYYY" or "I can't reproduce bug ZZZZZZ we need to ask more information".

I also thought about creating a new little post for every bug report checked (but that will create too much overhead in the forums database...)

-

The problem of such approach is that we don't have a central point to later check all the things.
We could simply "iterate" over each forum post, fetch every bug report "resolution" and paste it in a "central"/main forum post "BugDay Results".

---

You know more the forums (and its possible workflows and "hidden tools") more than me. Do you know if some tool could help us ?

Thanks for replying (and for being interested in the bugday initiative )

Hmmm, we could make it even more easy. Just let it work as usual klassroom, and for those not attending to irc, just let the mentor (or a moderator) post a log each... hour, or when something important was stated.
This way we can have students here at the board, possibly not involved in the irc session, but nevertheless being able to know what happens.

After some discussion with neverendingo on IRC we came up with a proposal draft:

We will have "BugWeeks" (with its own section)

Schedule:

Week -1: we will setup a poll to determine which will be the application to triage the next bugweek (suggested options will be the products with more bug reports on them). We could also discuss some other implementation details for that bugweek

Day 1 - Day 4 (tuesday-friday) we will setup the bugweek/bugday. We will also help the interested students to get a working and clean environment in order to test the bugs, and reply to common answers about the workflow and how to work with bugs (and with the bugs.kde.org interface). There are going to be articles explaining this too.

Day 5 - Day 6 (weekend) we will have the real bugday. The students will work on the assigned bug reports (batches of.) and post the preliminary results in the forum post. The mentors and other contributors and helpers will be on IRC and in the forums to answer specific questions.
(should we have separate forum threads for "preliminary results" and "questions" about every bugweek?)

Day 7 - End of that week (monday-sunday) the users could continue to work (if they want to) and the mentors and contributors will start evaluating the results of the bugweek and collecting the information to generate a summary (to later close reports or make other changes effective)
Mentors will evaluate the students work and encourage them to join us permanently.

Personally I think this is a great idea: a perfect opportunity to improve bug days and get people involved in KDE!

i think this is really a good idea, and i like the way you want to organize this