Hi All! So I'm trying to streamline and improve triaging efforts (again...I know). The idea is that some bugs should be getting higher priority for triaging in order to catch bad ones faster and prevent regressions from sticking around longer than need be. With this said I've made a short table with what I see as a good prioritization set, I want to move this to a wiki but first want input from anyone/everyone, if I'm missing something, should condense, etc...
These lists (at least priority 1-4) become much more manageable than staring at 1500+ unconfirmed bugs. Especially 1-3 should be getting triaged quickly (preferably < 7 days). This is all in an attempt to get all bugs triaged successfully within 30 days of report - we're a long ways off but slowly can get there. If the list isn't legible to you (it's a table copy/paste) please let me know and I'll email you a document directly. Priority Summary Rationale/Description FDO Link Additional Information 1 Bibisecting bibisectrequest (Linux Only) If a bisect is being requested it’s likely that this will get a regression fixed much faster and be a lot of help for developers *http://tinyurl.com/apk9q2j* *UNCONFIRMED, NEW, REOPENED, ASSIGNED* 2 Minor Release Regressions (Version 3.6) Recently a conversation on ESC made it clear that triaging minor release regressions is quite important for two reasons: Determine if it’s actually a regression for minor release (vs. .0 release) Minor releases should always be leading to additional stability of release (vs. .0 which usually comes with a lot of new features with potential problems) *http://tinyurl.com/b9omdfh* Only UNCONFIRMED TODO: Create new wiki describing what to do with these when triaging, additional steps required *Will need updated per minor release* 3 Minor Release Regressions (Version 4) Same rationale as above but version 4 – slightly lower priority since version 3 is still officially recommended *http://tinyurl.com/bkl3b2b* Only UNCONFIRMED TODO: Create new wiki describing what to do with these when triaging, additional steps required *Will need updated per minor release* 4 All Other Regressions Any other bug listed as a regression should be handled next. *http://tinyurl.com/b9f9csr* * * *(this is just a link to all bugs marked regression, including the bugs in the previous three links)* Only UNCONFIRMED TODO: Create new wiki describing what to do with these when triaging, additional steps required 5 Non-Regression Version 4 Bugs Bugs listed against 4 should be prioritized above version 3 bugs for a few reasons: 1. We can verify that it’s indeed only a version 4 bug, quite often the bug existed in 3 and version field should be updated 2. As we move forward we know version 4 will soon become the recommended version and thus gets a bit more attention 3. Keeping on track with <30 days untriaged – although we have a huge backlog, we should attempt to make it so no Version 4 bug report is left untouched for more than 30 days *http://tinyurl.com/bjjz3ho* * * *(this is all version 4 bugs including regressions)* Only UNCONFIRMED TODO: Clarify ideally what we should do with these on bug triage page (ie. we should check to see if they exist in 3.6 and change version if needed) *Will need updated per minor release* 6 Non-Regression Version 3.6 Bugs All non regression 3.6 bugs….just seems to be next logical list J 3.6 is still officially recommended *http://tinyurl.com/b8aly8k* * * *(this is all version 3.6 bugs including regressions)* *Will need updated per minor release* 7 All Remaining Bugs Everything else *http://tinyurl.com/aytplg9* * * *(all bugs reported against versions lower than 3.6 including see in summary & undefined)* Best, Joel -- *Joel Madero* LibreOffice QA Volunteer jmadero....@gmail.com
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
