Hello,
We didn't have a bug triage since May. I suggest organizing one in a few weeks (say 2?)
I agree to take care of this if it is widely supported. How about focusing on patch triage?
I mean reviewing bugs with patches attached but not in gerrit.
Any other subject would be good as well.
opinions?
Matanya
I see 3 types of bug triages:
a. Up-front * Confirming bugs and assigning them to developers. * STATUS is "UNCONFIRMED", "NEW", "REOPENED"; RESOLUTION is N/A
b. Verify fix * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")
c. Accept non-fix resolution * Accepting all non-fixed resolution. * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)
Here is a Wikimedia bug table report: https://bugzilla.wikimedia.org/report.cgi?y_axis_field=product&x_axis_fi... the different format at the bottom of the web page. Hope this helps,Al Snow ###########################################################################
Date: Thu, 16 Aug 2012 16:17:15 +0300 From: matanya@moses.co.il To: wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] organize a bug triage
Hello,
We didn't have a bug triage since May. I suggest organizing one in a few weeks (say 2?)
I agree to take care of this if it is widely supported. How about focusing on patch triage?
I mean reviewing bugs with patches attached but not in gerrit.
Any other subject would be good as well.
opinions?
Matanya
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Al,
On Thu, 2012-08-16 at 11:02 -0400, Al Snow wrote:
I see 3 types of bug triages:
Thanks. These could be added to https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad/Activities
Some more ideas could be to concentrate on a single module (e.g. extensions) or to update/try to reproduce issues that were reported for old versions and have not seen changes for a while (in Bugzilla's query.cgi under "Search By Change History" you can replace "Now" by e.g. "-731d" to get all tickets without any changes for the last two years). Or to update/retest the reports that you filed yourself, or.....
a. Up-front
- Confirming bugs and assigning them to developers.
- STATUS is "UNCONFIRMED", "NEW", "REOPENED"; RESOLUTION is N/A
I'd say that this normally requires knowledge which developers work on what. To me that makes it a harder task for "newbies" and might require people that have been in the community for quite a while. Just trying to clarify potential prerequisites.
b. Verify fix * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")
At least for more recent fixes this might require running (potentially unstable) code from latest git master instead of a (stable) tarball? Somebody please correct me if I'm wrong. Again, just potential prerequisites.
c. Accept non-fix resolution
- Accepting all non-fixed resolution.
- STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)
Sorry but I don't know what you mean by "accepting" here. :/
@matanya et al: I'd highly appreciate if you could try to document how to organize a bugday for future organizers (e.g. announcement, potential problems), and maybe alongside update (or identify gaps in) the Triage Guide at https://www.mediawiki.org/wiki/Bug_management/How_to_triage whenever needed. (But that guide is rather incomplete currently anyway.)
Thanks, andre
Andre,
c. Accept non-fix resolution
- Accepting all non-fixed resolution.
- STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)
Sorry but I don't know what you mean by "accepting" here. :/
When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID, WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN it or accept the resolution and change status to VERIFIED. Here is a chart with these RESOLUTIONS: https://bugzilla.wikimedia.org/reports.cgi?product=Wikimedia&banner=1&am...
Thanks for the question, Al Snow
From: andre_klapper@gmx.net To: wikitech-l@lists.wikimedia.org Date: Thu, 16 Aug 2012 19:21:12 +0200 Subject: Re: [Wikitech-l] organize a bug triage
Hi Al,
On Thu, 2012-08-16 at 11:02 -0400, Al Snow wrote:
I see 3 types of bug triages:
Thanks. These could be added to https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad/Activities
Some more ideas could be to concentrate on a single module (e.g. extensions) or to update/try to reproduce issues that were reported for old versions and have not seen changes for a while (in Bugzilla's query.cgi under "Search By Change History" you can replace "Now" by e.g. "-731d" to get all tickets without any changes for the last two years). Or to update/retest the reports that you filed yourself, or.....
a. Up-front
- Confirming bugs and assigning them to developers.
- STATUS is "UNCONFIRMED", "NEW", "REOPENED"; RESOLUTION is N/A
I'd say that this normally requires knowledge which developers work on what. To me that makes it a harder task for "newbies" and might require people that have been in the community for quite a while. Just trying to clarify potential prerequisites.
b. Verify fix * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")
At least for more recent fixes this might require running (potentially unstable) code from latest git master instead of a (stable) tarball? Somebody please correct me if I'm wrong. Again, just potential prerequisites.
c. Accept non-fix resolution
- Accepting all non-fixed resolution.
- STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)
Sorry but I don't know what you mean by "accepting" here. :/
@matanya et al: I'd highly appreciate if you could try to document how to organize a bugday for future organizers (e.g. announcement, potential problems), and maybe alongside update (or identify gaps in) the Triage Guide at https://www.mediawiki.org/wiki/Bug_management/How_to_triage whenever needed. (But that guide is rather incomplete currently anyway.)
Thanks, andre -- Andre Klapper (maemo.org bugmaster & GNOME Bugsquad) http://blogs.gnome.org/aklapper/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Al,
[Expectations, workflows and manpower among FOSS projects differ so please take my comments with a grain of salt as I don't follow the Wikimedia project that closely.]
On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
c. Accept non-fix resolution
- Accepting all non-fixed resolution.
- STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)
Sorry but I don't know what you mean by "accepting" here. :/
When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID, WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN it or accept the resolution and change status to VERIFIED.
...or to just leave a report as it is? :)
REOPENing normally happens if the reporter, developer or another party interested in fixing the issue realizes that a committed fix did not fix the issue, or to signal disagreement. I'm not convinced if triagers can help here to save any of those persons some time.
Also I don't really see who it helps to verify RESOLVED DUPLICATE. Personally I rather consider it a waste of time (anybody is free to disagree of course) as efforts are better spent on general triaging like identifying duplicates etc. which seems to be a bigger help for users and developers.
For the other four options I normally leave it to the reporter. For example verifying a WONTFIX (=stating for a second time that the request will not receive a fix) might make a reporter feel less acknowledged for spending time on reporting a bug or request.
andre
PS: For anybody _really_ interested in discussing the use of the VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla dev-platform/dev-quality mailing lists at https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9S...]
Triaging already closed bugs seems like a huge waste of time when there's so many open bugs that need love.
-Chad On Aug 16, 2012 1:53 PM, "Andre Klapper" andre_klapper@gmx.net wrote:
Hi Al,
[Expectations, workflows and manpower among FOSS projects differ so please take my comments with a grain of salt as I don't follow the Wikimedia project that closely.]
On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
c. Accept non-fix resolution
- Accepting all non-fixed resolution.
- STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5
non-"FIXED" RESOLUTION values)
Sorry but I don't know what you mean by "accepting" here. :/
When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID, WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN it or accept the resolution and change status to VERIFIED.
...or to just leave a report as it is? :)
REOPENing normally happens if the reporter, developer or another party interested in fixing the issue realizes that a committed fix did not fix the issue, or to signal disagreement. I'm not convinced if triagers can help here to save any of those persons some time.
Also I don't really see who it helps to verify RESOLVED DUPLICATE. Personally I rather consider it a waste of time (anybody is free to disagree of course) as efforts are better spent on general triaging like identifying duplicates etc. which seems to be a bigger help for users and developers.
For the other four options I normally leave it to the reporter. For example verifying a WONTFIX (=stating for a second time that the request will not receive a fix) might make a reporter feel less acknowledged for spending time on reporting a bug or request.
andre
PS: For anybody _really_ interested in discussing the use of the VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla dev-platform/dev-quality mailing lists at
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9S...]
-- Andre Klapper (maemo.org bugmaster & GNOME Bugsquad) http://blogs.gnome.org/aklapper/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks Chad and Andre for your responses. I am new to the community and did not know that RESOLVED bugs were considered CLOSED. Thanks for the update.
Al Snow
Date: Thu, 16 Aug 2012 14:01:33 -0400 From: innocentkiller@gmail.com To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] organize a bug triage
Triaging already closed bugs seems like a huge waste of time when there's so many open bugs that need love.
-Chad On Aug 16, 2012 1:53 PM, "Andre Klapper" andre_klapper@gmx.net wrote:
Hi Al,
[Expectations, workflows and manpower among FOSS projects differ so please take my comments with a grain of salt as I don't follow the Wikimedia project that closely.]
On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
c. Accept non-fix resolution
- Accepting all non-fixed resolution.
- STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5
non-"FIXED" RESOLUTION values)
Sorry but I don't know what you mean by "accepting" here. :/
When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID, WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN it or accept the resolution and change status to VERIFIED.
...or to just leave a report as it is? :)
REOPENing normally happens if the reporter, developer or another party interested in fixing the issue realizes that a committed fix did not fix the issue, or to signal disagreement. I'm not convinced if triagers can help here to save any of those persons some time.
Also I don't really see who it helps to verify RESOLVED DUPLICATE. Personally I rather consider it a waste of time (anybody is free to disagree of course) as efforts are better spent on general triaging like identifying duplicates etc. which seems to be a bigger help for users and developers.
For the other four options I normally leave it to the reporter. For example verifying a WONTFIX (=stating for a second time that the request will not receive a fix) might make a reporter feel less acknowledged for spending time on reporting a bug or request.
andre
PS: For anybody _really_ interested in discussing the use of the VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla dev-platform/dev-quality mailing lists at
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9S...]
-- Andre Klapper (maemo.org bugmaster & GNOME Bugsquad) http://blogs.gnome.org/aklapper/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/16/2012 09:17 AM, matanya wrote:
We didn't have a bug triage since May. I suggest organizing one in a few weeks (say 2?)
Wow! Thanks for taking this on! I'm busy with non-MW work, but I do have some time to help out.
Please CC me personally on any triage announcements or ping me on IRC (hexmode). Thanks!
- -- http://hexmode.com/
Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges
I think this is a great idea, but I also have a new idea for how we might go about using the RESOLVED -> VERIFIED -> CLOSED workflow in BugZilla, rather than just treating resolved as closed. One thing I noticed about MW is that we're very much lacking in the test planning area. What if a bug is marked as verified if either a) somebody makes and commits a test case for it or b) it is determined that a test case is not applicable. That way we'll have automated tests ensuring every bug we fix doesn't come back again. Any thoughts?
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sat, Aug 18, 2012 at 11:31 AM, Mark A. Hershberger mah@everybody.orgwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/16/2012 09:17 AM, matanya wrote:
We didn't have a bug triage since May. I suggest organizing one in a few weeks (say 2?)
Wow! Thanks for taking this on! I'm busy with non-MW work, but I do have some time to help out.
Please CC me personally on any triage announcements or ping me on IRC (hexmode). Thanks!
Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQL7VXc17xCi38v/URAsV7AKCiYFvnnIfSu8sU+/OvVxnboWQWWwCghdMy JpR0it7vfHlOOfr8OX5VbF8= =iBFq -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sun, 2012-08-19 at 01:42 -0400, Tyler Romeo wrote:
I think this is a great idea, but I also have a new idea for how we might go about using the RESOLVED -> VERIFIED -> CLOSED workflow in BugZilla, rather than just treating resolved as closed. One thing I noticed about MW is that we're very much lacking in the test planning area. What if a bug is marked as verified if either a) somebody makes and commits a test case for it or b) it is determined that a test case is not applicable. That way we'll have automated tests ensuring every bug we fix doesn't come back again. Any thoughts?
I fail to see a strong relation with the VERIFIED status. One could also argue in favor of writing a testcase together with writing the fix for a specific bug report (so relating it to RESOLVED FIXED instead).
But this is getting off-topic for the "bug triage" subject anyway. :)
andre
wikitech-l@lists.wikimedia.org