Hello,
Paul F. Johnson wrote:
I think that putting the following couple of pages together on the Wiki :
- General informations on bug days :
* What is a bug day ?
* Who can attempt ?
This would need to be split and preferably, peer mentored.
I don't understand what you think should be peer mentored. Do you mean
that attempting a bug day should be peer mentored ? Or were you
mentionning writing up these pages should be peer mentored ?
For example, user
"a" may write and compile some code which clearly shows (say) MWF is broken
for spot colours. This is submitted and a peer proofs the code to see that
it's not user "a" who has made a boo-boo before submitting as a real bug.
I totally agree with that, it is a typical use case of a bug day :-).
* When does it take place ?
Logistically, the third is the biggest one given the diversity of places
people are (I'm in the UK for instance while Peter (say) is out by 6 hours
from GMT). I'd suggest that the bug "day" would need to be split into two half
days for when the developers are around.
IIRC, the GNOME project has bug days from 15 PM to 21 PM UTC, which is
nice during the week.
I agree that bug days during the week-end would be fine too. Maybe we
could split bug days with one in the middle of the week and one during
the week-end ?
- Detailed informations on what to do during a bug day :
This can be split in two parts : bug squashing and bug triaging :
* As for bug triaging :
* How to find bug reports that are most important to triage ?
* How to triage a bug report ?
All bugs are important, just some more than others. I remember finding one
very small bug in an application called TechWriterPro (it's a RISC OS app)
which when investigated, proved to be massive and set back the release
schedule by a month.
I agree too, but there are some special cases for which you could want
to focus your attention on a certain kind of bugs (just before a
release, a feature freeze, whatever).
* As for bug squashing :
* How to find bug confirmed bug reports that are most important to fix ?
* How to fix a bug ?
Ideally, the developers, though others should never be discouraged. This is
were the peer review comes into it's own - bugs which aren't bugs never get
past the reviewer.
I agree too : triaging bug is the primary goal, nevertheless fixing them
is great :-).
Would this bug day be best set on a saturday
or sunday though?
What do you think about the middle of the week/week-end schedule i
mentionned above ?
Maybe we should set a goal for the first milestone, like having a bug
day next saturday, or on 09/10 ? By trying to get things done, we will
probably come across some problems that we'll resolve, and then we can
go from there for the future bug days.
Again, looking forward to hearing from you :-).
All the best,
--
Julien Gilli
IDEALX http://www.idealx.com/
_______________________________________________
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
