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&datasets=INVALID&datasets=WONTFIX&datasets=LATER&datasets=DUPLICATE&datasets=WORKSFORME Thanks for the question, Al Snow > From: [email protected] > To: [email protected] > 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
