Bug Triage Meeting irc.freenode.net #fedora-meeting Tuesday @ 15:00 UTC/10 AM EST
Agenda
BugZappers signatures for bugzilla - iarlyy was working on the greasemonkey script and I believe has it finished.
Bug Triage Days Discuss implementing bug triage days.
Anything missed or something you'd like added to the agenda, please add it here.
See you on Tuesday.
Edward (TK009)
mcepl worked in the last version and finished it, we may discuss new features to add to the script.
Regards,
- - iarly selbir ( ski0s )
:wq!
On Mon, Feb 23, 2009 at 6:23 PM, TK009 john.brown009@gmail.com wrote:
Bug Triage Meeting irc.freenode.net #fedora-meeting Tuesday @ 15:00 UTC/10 AM EST
Agenda
BugZappers signatures for bugzilla - iarlyy was working on the greasemonkey script and I believe has it finished.
Bug Triage Days Discuss implementing bug triage days.
Anything missed or something you'd like added to the agenda, please add it here.
See you on Tuesday.
Edward (TK009)
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
On Mon, 2009-02-23 at 13:23 -0500, TK009 wrote:
Bug Triage Meeting irc.freenode.net #fedora-meeting Tuesday @ 15:00 UTC/10 AM EST
Agenda
BugZappers signatures for bugzilla - iarlyy was working on the greasemonkey script and I believe has it finished.
Bug Triage Days Discuss implementing bug triage days.
Anything missed or something you'd like added to the agenda, please add it here.
Could we talk about having a mentoring system for new triagers?
Getting started triaging is the sort of thing that benefits from personal advice. We have a few people who are enthusiastic about joining in with Bugzappers, but the path isn't that well-laid out at present...I think a mentoring system might help.
On Mon, Feb 23, 2009 at 1:32 PM, Adam Williamson awilliam@redhat.com wrote:
On Mon, 2009-02-23 at 13:23 -0500, TK009 wrote:
Bug Triage Meeting irc.freenode.net #fedora-meeting Tuesday @ 15:00 UTC/10 AM EST
Agenda
BugZappers signatures for bugzilla - iarlyy was working on the greasemonkey script and I believe has it finished.
Bug Triage Days Discuss implementing bug triage days.
Anything missed or something you'd like added to the agenda, please add it here.
Could we talk about having a mentoring system for new triagers?
Getting started triaging is the sort of thing that benefits from personal advice. We have a few people who are enthusiastic about joining in with Bugzappers, but the path isn't that well-laid out at present...I think a mentoring system might help. -- Adam Williamson
I think this is part of the point of Bug Triage Days. In the past we have allocated part of our meeting time to running through a few bugs, but I do not think that is effect use of meeting time even though it was very effective at training people. At one point we all put up "office hours" stating when help would be available on fedora-bugzappers for triaging bugs. Perhaps this should be added to tomorrow agenda.
-- Brennan Ashton
On Mon, 2009-02-23 at 13:38 -0800, Brennan Ashton wrote:
On Mon, Feb 23, 2009 at 1:32 PM, Adam Williamson awilliam@redhat.com wrote:
On Mon, 2009-02-23 at 13:23 -0500, TK009 wrote:
Bug Triage Meeting irc.freenode.net #fedora-meeting Tuesday @ 15:00 UTC/10 AM EST
Agenda
BugZappers signatures for bugzilla - iarlyy was working on the greasemonkey script and I believe has it finished.
Bug Triage Days Discuss implementing bug triage days.
Anything missed or something you'd like added to the agenda, please add it here.
Could we talk about having a mentoring system for new triagers?
Getting started triaging is the sort of thing that benefits from personal advice. We have a few people who are enthusiastic about joining in with Bugzappers, but the path isn't that well-laid out at present...I think a mentoring system might help. -- Adam Williamson
I think this is part of the point of Bug Triage Days. In the past we have allocated part of our meeting time to running through a few bugs, but I do not think that is effect use of meeting time even though it was very effective at training people. At one point we all put up "office hours" stating when help would be available on fedora-bugzappers for triaging bugs. Perhaps this should be added to tomorrow agenda.
Well, it's a bit different, but I agree it would be a good thing to do in Triage Days - help out whatever newbies showed up that week. :)
https://fedoraproject.org/wiki/BugZappers/Goals
looks a bit crufty.
Unless goals have already been set somewhere else, there are several worthy goals I can think of, depending on what the priorities are and how many people-hours are available each week. There doesn't need to be a specific deadline, but on Wikipedia when dealing with these housekeeping queues we often just say "we're focusing effort on X" and then cheer when we finish that part of the job.
People having the worst problems:
* Zero out the number of NEW bugs from Fedora version 1-8 (handful) * Triage all NEW bugs that are Severity=urgent (104) * Triage all NEW bugs that are Severity=high (605)
Cleaning up the "easy" bugs (likely to have been looked at already by the developer) from the end of the queue (by date):
* Triage all NEW bugs from 2004, 2005, and 2006 (<50) * Triage all NEW bugs from 2007 (about 400 + 300 merge review) * Etc. * Eventually all bugs should be looked at within no more than _ days, so the system feels responsive and easy problems can be solved in a reasonable period.
Catching bugs as they come in:
* Triage all the bugs filed within the past 30 days, so that the triage queue never grows. (~2000/month) * Rely on EOL process to deal with bugs at the end of the queue, so eventually we will completely catch up.
By the way, There are about 300 bugs from 2007-01-31 with "Merge Review" in the summary, filed against the component "Package Review". I would expect:
https://fedoraproject.org/wiki/BugZappers/Special_Procedures
to tell triagers what to do about these bugs, but there's no mention.
Another thing that could be done is that if there are specific developers that are feeling overwhelmed with bugs, they could request that triagers clean out their components in a focused effort.
-B.
On Mon, Feb 23, 2009 at 7:49 PM, Christopher Beland beland@alum.mit.edu wrote:
https://fedoraproject.org/wiki/BugZappers/Goals
looks a bit crufty.
Unless goals have already been set somewhere else, there are several worthy goals I can think of, depending on what the priorities are and how many people-hours are available each week. There doesn't need to be a specific deadline, but on Wikipedia when dealing with these housekeeping queues we often just say "we're focusing effort on X" and then cheer when we finish that part of the job.
People having the worst problems:
- Zero out the number of NEW bugs from Fedora version 1-8 (handful)
- Triage all NEW bugs that are Severity=urgent (104)
- Triage all NEW bugs that are Severity=high (605)
Cleaning up the "easy" bugs (likely to have been looked at already by the developer) from the end of the queue (by date):
- Triage all NEW bugs from 2004, 2005, and 2006 (<50)
- Triage all NEW bugs from 2007 (about 400 + 300 merge review)
- Etc.
- Eventually all bugs should be looked at within no more than _ days,
so the system feels responsive and easy problems can be solved in a reasonable period.
Catching bugs as they come in:
- Triage all the bugs filed within the past 30 days, so that the
triage queue never grows. (~2000/month)
- Rely on EOL process to deal with bugs at the end of the queue, so
eventually we will completely catch up.
By the way, There are about 300 bugs from 2007-01-31 with "Merge Review" in the summary, filed against the component "Package Review". I would expect:
https://fedoraproject.org/wiki/BugZappers/Special_Procedures
to tell triagers what to do about these bugs, but there's no mention.
Another thing that could be done is that if there are specific developers that are feeling overwhelmed with bugs, they could request that triagers clean out their components in a focused effort.
-B.
This is all very helpful feedback, right now what we are working on is narrowing down our goals, to start chipping away the bug count down to a manageable amount. I would like to point out however that Merge Reviews and Review Requests do not really fall under our group. They are part of packaging.
-- Brennan Ashton
On Mon, 2009-02-23 at 20:01 -0800, Brennan Ashton wrote:
This is all very helpful feedback, right now what we are working on is narrowing down our goals, to start chipping away the bug count down to a manageable amount. I would like to point out however that Merge Reviews and Review Requests do not really fall under our group. They are part of packaging.
Right, that's what makes them a special case. Is the appropriate thing to do something like "adjust search parameters to skip these bugs" or "change all to ASSIGNED without reading to get them off our list"?
-B.
2009/2/24 Christopher Beland beland@alum.mit.edu
On Mon, 2009-02-23 at 20:01 -0800, Brennan Ashton wrote:
This is all very helpful feedback, right now what we are working on is narrowing down our goals, to start chipping away the bug count down to a manageable amount. I would like to point out however that Merge Reviews and Review Requests do not really fall under our group. They are part of packaging.
Right, that's what makes them a special case. Is the appropriate thing to do something like "adjust search parameters to skip these bugs" or "change all to ASSIGNED without reading to get them off our list"?
The premade queries on the wiki already exclude anything for component PackageReview.. People get a little annoyed if we touch package reviews.
On Tue, 2009-02-24 at 15:13 +0000, John5342 wrote:
The premade queries on the wiki already exclude anything for component PackageReview.. People get a little annoyed if we touch package reviews.
OK, I updated https://fedoraproject.org/wiki/BugZappers/Special_Procedures to say to leave these alone.
-B.
On 2009-02-24, 03:49 GMT, Christopher Beland wrote:
https://fedoraproject.org/wiki/BugZappers/Goals
looks a bit crufty.
Unless goals have already been set somewhere else, there are several worthy goals I can think of, depending on what the priorities are and how many people-hours are available each week. There doesn't need to be a specific deadline, but on Wikipedia when dealing with these housekeeping queues we often just say "we're focusing effort on X" and then cheer when we finish that part of the job.
You are very right, except ... let me add some comments.
- Zero out the number of NEW bugs from Fedora version 1-8
(handful)
Not sure I understand this? All bugs from Fedora <= 8 should be close this time, shouldn't they?
- Triage all NEW bugs that are Severity=urgent (104)
- Triage all NEW bugs that are Severity=high (605)
Given that Severity and Priority fields are changeable by reporters they are almost useless and they are never used by developers. I am trying a quixotic attempt to fix them xorg bugs, but I am not sure whether it is good for anything.
- Eventually all bugs should be looked at within no more than days, so the system feels responsive and easy problems can be solved in a reasonable period.
We tried this before and the general conclusion is that this is a quite good way how to loose volunteers, because the effort is so boring, that no-one is able to sustain it (unless he is paid for it, like me ;-)). Current wisdom is that it is much better to assign yourself to some pack of components, get in touch with their developers/maintainers and help them to clean their stuff. There are still available slots (compare https://fedoraproject.org/wiki/BugZappers/components and https://fedoraproject.org/wiki/BugZappers/ActiveTriagers)!
By the way, There are about 300 bugs from 2007-01-31 with "Merge Review" in the summary, filed against the component "Package Review". I would expect:
https://fedoraproject.org/wiki/BugZappers/Special_Procedures
to tell triagers what to do about these bugs, but there's no mention.
Because it requires quite special ways -- take a look at https://fedoraproject.org/wiki/Package_Review_Process. If you want to volunteer on cleaning up Package Reviews (of which Merge Reviews are subset) you are absolutely more than welcome, but it is slightly different kind of job -- not that much more difficult, but you have to study different things than for the regular bug zapping.
So, yes our BugZappers/ wiki is kind of messy at the moment (and it is wiki, so if you want to fix it, go ahead), but there actually is some system in our madness.
Best,
Matěj Cepl
On Tue, 2009-02-24 at 10:54 +0100, Matej Cepl wrote:
- Zero out the number of NEW bugs from Fedora version 1-8
(handful)
Not sure I understand this? All bugs from Fedora <= 8 should be close this time, shouldn't they?
Yes, but people are constantly filing new bugs against EOL versions, and these bugs continually need to be closed with a friendly stock message to upgrade to a supported version.
-B.
On Tuesday 24 February 2009 17:03:04 Christopher Beland wrote:
Yes, but people are constantly filing new bugs against EOL versions, and these bugs continually need to be closed with a friendly stock message to upgrade to a supported version.
You have a version that my hardware supports properly yet?
;o)
On Thu, 2009-02-26 at 17:57 +0000, Bill Crawford wrote:
You have a version that my hardware supports properly yet?
;o)
I have no idea what kind of hardware you have, but you can certainly try installing Rawhide on it or running it from Live media. Usually hardware support gets better over time, so I'm not sure why that would be an impediment to upgrading.
-B.
2009/2/26 Christopher Beland beland@alum.mit.edu
On Thu, 2009-02-26 at 17:57 +0000, Bill Crawford wrote:
You have a version that my hardware supports properly yet?
;o)
I have no idea what kind of hardware you have, but you can certainly try installing Rawhide on it or running it from Live media. Usually hardware support gets better over time, so I'm not sure why that would be an impediment to upgrading.
in the same time is true that support for older hardware is slowly dropped.
-B.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
On Thu, Feb 26, 2009 at 10:50 PM, cornel panceac cpanceac@gmail.com wrote:
2009/2/26 Christopher Beland beland@alum.mit.edu
On Thu, 2009-02-26 at 17:57 +0000, Bill Crawford wrote:
You have a version that my hardware supports properly yet?
;o)
I have no idea what kind of hardware you have, but you can certainly try installing Rawhide on it or running it from Live media. Usually hardware support gets better over time, so I'm not sure why that would be an impediment to upgrading.
in the same time is true that support for older hardware is slowly dropped.
Naysayer that I am, I'd like to see BZ reports for both Bill's unsupported hardware, and for the older hardware that no longer works.
Thanks, jerry
2009/2/27 Jerry Amundson jamundso@gmail.com
On Thu, Feb 26, 2009 at 10:50 PM, cornel panceac cpanceac@gmail.com wrote:
2009/2/26 Christopher Beland beland@alum.mit.edu
On Thu, 2009-02-26 at 17:57 +0000, Bill Crawford wrote:
You have a version that my hardware supports properly yet?
;o)
I have no idea what kind of hardware you have, but you can certainly try installing Rawhide on it or running it from Live media. Usually hardware support gets better over time, so I'm not sure why that would be an impediment to upgrading.
in the same time is true that support for older hardware is slowly
dropped.
Naysayer that I am, I'd like to see BZ reports for both Bill's unsupported hardware, and for the older hardware that no longer works.
Thanks, jerry
like this?
https://bugzilla.redhat.com/show_bug.cgi?id=458226
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
On Friday 27 February 2009 16:15:58 cornel panceac wrote:
2009/2/27 Jerry Amundson jamundso@gmail.com
On Thu, Feb 26, 2009 at 10:50 PM, cornel panceac cpanceac@gmail.com
wrote:
2009/2/26 Christopher Beland beland@alum.mit.edu
On Thu, 2009-02-26 at 17:57 +0000, Bill Crawford wrote:
You have a version that my hardware supports properly yet?
;o)
I have no idea what kind of hardware you have, but you can certainly try installing Rawhide on it or running it from Live media. Usually hardware support gets better over time, so I'm not sure why that would be an impediment to upgrading.
in the same time is true that support for older hardware is slowly
dropped.
Naysayer that I am, I'd like to see BZ reports for both Bill's unsupported hardware, and for the older hardware that no longer works.
Thanks, jerry
like this?
Actually, http://bugs.freedesktop.org/show_bug.cgi?id=18160 was the one I CCed on, because it looked like the same problem I was seeing.
However, currently, POSTing secondary video cards doesn't work at all, and even F10 with all updates (at least as of about four days ago) can't actually drive the 3 PCI video cards in my desktop system at work.
Home machine is fine, because it only has one graphics card in it.
It's an upstream issue, and I have been told several times that it will be dealt with eventually, but in the meantime, I'm stuck on F8 at work.
On Tue, Feb 24, 2009 at 12:03:04PM -0500, Christopher Beland wrote:
On Tue, 2009-02-24 at 10:54 +0100, Matej Cepl wrote:
- Zero out the number of NEW bugs from Fedora version 1-8
(handful)
Not sure I understand this? All bugs from Fedora <= 8 should be close this time, shouldn't they?
Yes, but people are constantly filing new bugs against EOL versions, and these bugs continually need to be closed with a friendly stock message to upgrade to a supported version.
Why not remove those versions from being able to be selected when filing new bugs in bugzilla?
Chuck Anderson wrote:
On Tue, Feb 24, 2009 at 12:03:04PM -0500, Christopher Beland wrote:
On Tue, 2009-02-24 at 10:54 +0100, Matej Cepl wrote:
- Zero out the number of NEW bugs from Fedora version 1-8
(handful)
Not sure I understand this? All bugs from Fedora <= 8 should be close this time, shouldn't they?
Yes, but people are constantly filing new bugs against EOL versions, and these bugs continually need to be closed with a friendly stock message to upgrade to a supported version.
Why not remove those versions from being able to be selected when filing new bugs in bugzilla?
We've checked into this before and we can't. I can't remember the exact reason why. The only way I've been told we could do this was if each Fedora version was a separate "product" instead of the way it currently is with 'product->fedora' and 'version->{1-10,rawhide}' we would have 'product->fedora10' and version would be less meaningful. The RHEL products follow this methodology.
John
On Tue, 2009-02-24 at 10:54 +0100, Matej Cepl wrote:
Given that Severity and Priority fields are changeable by reporters they are almost useless and they are never used by developers. I am trying a quixotic attempt to fix them xorg bugs, but I am not sure whether it is good for anything.
For Mandriva I considered them important and made it part of triage team's job to set them. I think this would be useful if we can do it consistently, because then maintainers would be able to trust the settings for triaged bugs. Reporters generally don't change them again after they've been triaged, in my experience of this system.
On 2009-02-23, 21:32 GMT, Adam Williamson wrote:
Getting started triaging is the sort of thing that benefits from personal advice. We have a few people who are enthusiastic about joining in with Bugzappers, but the path isn't that well-laid out at present...I think a mentoring system might help.
If any such person would like my tutoring, I am avaiable during the day either as mcepl on Freenode or on Jabber account mcepl at ceplovi.cz Jabber server (making the JID knowingly more difficult for spambots to harvest).
Best,
Matěj
On Mon, Feb 23, 2009 at 01:32:13PM -0800, Adam Williamson wrote:
On Mon, 2009-02-23 at 13:23 -0500, TK009 wrote:
Bug Triage Meeting irc.freenode.net #fedora-meeting Tuesday @ 15:00 UTC/10 AM EST
Agenda
BugZappers signatures for bugzilla - iarlyy was working on the greasemonkey script and I believe has it finished.
Bug Triage Days Discuss implementing bug triage days.
Anything missed or something you'd like added to the agenda, please add it here.
Could we talk about having a mentoring system for new triagers?
Getting started triaging is the sort of thing that benefits from personal advice. We have a few people who are enthusiastic about joining in with Bugzappers, but the path isn't that well-laid out at present...I think a mentoring system might help.
Agreed. This helped me when I started triaging bugs a while back. (Granted, I haven't had time to do many lately, but there was a short period where I was pretty active.)
Allow me to be a little pie-in-the-sky for a moment. This need is one of the reasons I'm so excited about Moksha[1]. Its live collaborative apps will eventually allow us to plop someone down in a web-based interface that gives them instant connection to bugzilla feeds, IRC chat, etc. It should also be able to introduce them to the group, so they don't have to go through all the steps our group-joining processes currently require.
A mentor seeing the introduction in the IRC channel could pop up like a groundhog and say, "Hi <Joe>, I see you're interested in triaging, and that you're using the Fedora Community portal. If you look on the left side of your web page you'll see a list of new Rawhide bugs. Would you like me to help you triage bug #<NNNNNN> so you can get a feel for how this works?"
Anyway, that's the pie-in-the-sky vision. Let's not waste time on this thread picking it apart or finding other things we could add to it. I only mention it because the idea of mentoring is so important to Fedora as a contributor-centric project. We must be prepared with a process and people to support new contributors who are interested in getting their hands dirty, starting from the minute they show up. The longer it takes for us to take advantage of that enthusiasm, the more it wanes.
= = = [1] http://fedorahosted.org/moksha