Streamlining & Improving Triage Efforts

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.dev@gmail.com