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&a…
Thanks for the question,
Al Snow
> From: andre_klapper(a)gmx.net
> To: wikitech-l(a)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(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l