[PROPOSAL] QA Prioritization on Reports

["Dennis E. Hamilton" <or...@apache.org>]

Hi Alex,

Thank you for your willingness.

I don't think we are as organized as you seem to be thinking (and happy to be mistaken).

I am providing a proposal in response to your great question.

This may be too many words. All assistance in making this clear, with any questions, suggestions, objections, whatever: please provide on this thread.

 - Dennis

PROPOSAL

We have a growing backlog (also known as a technical debt) and an useful way to deal with that is,

 1. Stop (by progressively reducing the rate of growth of) the growth of the backlog.  That means looking at new ones to see how they can be confirmed, and resolved or assignable to a developer in the case of confirmed defects.  (Even if you are prepared to work on it and own it, follow these stages so others know what is going on.)

 2. Work on the older ones (what is called technical debt as they age).  I would suggest, in particular, older ones for which (1) duplicates keep showing up or (2) there is still ongoing comments against them.  There are ways to detect those, but watching the OOo-issues list is a big start.  I assume everyone on the QA list is also subscribed to <is...@openoffice.apache.org>.

 3. GOOD PRACTICE.  Because this is a self-organizing voluntary effort, what I recommend is that, when an issue or block of issues is taken on for QA scrutiny, post a message *here* announcing the numbers or ranges that are being taken on.  Also, add yourself as the QA contact on the issue, so others know there as well.  That provides a heartbeat and indication that others should look for low-hanging fruit elsewhere.  When you are done with ones you have examined (no matter what the outcome), announce that and adjust the QA contact on the issue if necessary.

I think that is an ideal practice, all other factors considered.

EXCEPTION

When the project is driving for a release, there will be release blockers.  Keep an eye on those.  Also, be prepared to do a regression test, if possible, to confirm whether the release candidate appears to cure the defect or not.  This should involve follow-up at the issue.  Not all reporters are in a position to install release candidates in a safe way.  When the release happens, that is a good time to see if the reporters can then update and confirm whether the problem is cured.  


-----Original Message-----
From: Alex Korsakov [mailto:aleksey.korsakov85@gmail.com] 
Sent: Friday, September 18, 2015 04:11
To: qa@openoffice.apache.org
Subject: [QA]Some batch of reports

Good day to all! I'm a newbie in a QA, but I understand "how it works" 
and already work with unconfirmed defects in Bugzilla, but I wanna ask 
you to assign to me some batch of reports. I think it would be more 
productive for me. Thanks.

PS sorry for bad English


---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org

FW: [PROPOSAL] QA Prioritization on Reports

["Dennis E. Hamilton" <or...@apache.org>]

Although of specific importance for QA, this deserves awareness and consideration in the boarder dev community.  Sorry, I was focused too narrowly,

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:orcmid@apache.org] 
Sent: Friday, September 18, 2015 08:29
To: qa@openoffice.apache.org
Cc: 'Alex Korsakov' <al...@gmail.com>
Subject: [PROPOSAL] QA Prioritization on Reports

Hi Alex,

Thank you for your willingness.

I don't think we are as organized as you seem to be thinking (and happy to be mistaken).

I am providing a proposal in response to your great question.

This may be too many words. All assistance in making this clear, with any questions, suggestions, objections, whatever: please provide on this thread.

 - Dennis

PROPOSAL

We have a growing backlog (also known as a technical debt) and an useful way to deal with that is,

 1. Stop (by progressively reducing the rate of growth of) the growth of the backlog.  That means looking at new ones to see how they can be confirmed, and resolved or assignable to a developer in the case of confirmed defects.  (Even if you are prepared to work on it and own it, follow these stages so others know what is going on.)

 2. Work on the older ones (what is called technical debt as they age).  I would suggest, in particular, older ones for which (1) duplicates keep showing up or (2) there is still ongoing comments against them.  There are ways to detect those, but watching the OOo-issues list is a big start.  I assume everyone on the QA list is also subscribed to <is...@openoffice.apache.org>.

 3. GOOD PRACTICE.  Because this is a self-organizing voluntary effort, what I recommend is that, when an issue or block of issues is taken on for QA scrutiny, post a message *here* announcing the numbers or ranges that are being taken on.  Also, add yourself as the QA contact on the issue, so others know there as well.  That provides a heartbeat and indication that others should look for low-hanging fruit elsewhere.  When you are done with ones you have examined (no matter what the outcome), announce that and adjust the QA contact on the issue if necessary.

I think that is an ideal practice, all other factors considered.

EXCEPTION

When the project is driving for a release, there will be release blockers.  Keep an eye on those.  Also, be prepared to do a regression test, if possible, to confirm whether the release candidate appears to cure the defect or not.  This should involve follow-up at the issue.  Not all reporters are in a position to install release candidates in a safe way.  When the release happens, that is a good time to see if the reporters can then update and confirm whether the problem is cured.  


-----Original Message-----
From: Alex Korsakov [mailto:aleksey.korsakov85@gmail.com] 
Sent: Friday, September 18, 2015 04:11
To: qa@openoffice.apache.org
Subject: [QA]Some batch of reports

Good day to all! I'm a newbie in a QA, but I understand "how it works" 
and already work with unconfirmed defects in Bugzilla, but I wanna ask 
you to assign to me some batch of reports. I think it would be more 
productive for me. Thanks.

PS sorry for bad English


---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org