Bruno Postle wrote: > It's the result of not maintaining the tracker very well.
AFAIK you're the only person who works consistently through the trackers. Others, including me, look occasionally at it. Do you see ways how we can help you maintain the tracker better? should we codify the process of tracker maintenance? As a minimum I would suggest keeping track of new vs. existing bugs; a set of rules on how to triage new bugs; and a way to tell other volunteers what dateline divides the existing vs. new bugs (i.e. when were the bugs triaged last). Things would work this way: 1. when a volunteer has time to go over the new bugs, he/she goes to the bugtracker, filters for "Open" status and sort by "Opened": <http://sourceforge.net/tracker/?words=tracker_browse&sort=open_date&sortdir=asc&group_id=77506&atid=550441&status=1> 2. the volunteer scrolls down to the last "cutoff date" and looks at each new bug report added after the cutoff date. 3. For each bug report: - determine if it is a duplicate or can otherwise be closed - if it is anonymous, determine the likelyhood that we may need additional feedback and eventually set it to pending status (we may want to word out a policy about anonymous bug reports) - assign Category, Group, Priority - when in doubt, ask on the mailing list - add clarifying questions to the bug ticket if applicable - if necessary, post a message to the mailing list about the new bug. e.g. if the bug report is anonymous and we need more information, post to the mailing list, chances are the reporter is here and just did not log on to SF 4. at the end of the day, post a message to the mailing list saying that bugs from old cutoff date to new cutoff date have been triaged. Ideally the new cutoff date is today, but sometimes people don't have the time to process all the new bugs that are in the tracker, and we need a way to enable team work on this. So the new cutoff date is the pointer for the next bug triage volunteer. > Maybe we should just use the numeric scoring and remove the 'hugin > critical' group (we don't have a 'batch processor critical' group). > > i.e. '9' is a blocker. I second that. I started updating <http://wiki.panotools.org/Development_of_Open_Source_tools> and specific to this subject I edited under <http://wiki.panotools.org/Development_of_Open_Source_tools#Release_Cycle> the link to the bugs that will have been fixed before the next Hugin will be released. Feel free to add/edit/change/improve. I'm just me, pushing for the systematic approach :) Yuv --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
