On 20.09.2012 16:54, TJ Frazier wrote:
On 9/20/2012 00:12, Herbert Duerr wrote:
On 19.09.2012 20:34, Ariel Constenla-Haile wrote:
On Wed, Sep 19, 2012 at 02:24:11PM +0200, Oliver Brinzing wrote:
Hi Regina,

Your own new issue should be UNCONFIRMED. Someone else should confirm
your issue, if possible on a different operating system.

i am pretty sure that i did not set the "confirmed" status when
submitting a new issue,
default status is "confirmed" - and you have to select "Show Advanced
Fields"
to see the listbox ... this seems to be the root cause of the problem
...

I agree with Oliver, the default status should be set to UNCONFIRMED
even if the reporter has canconfirm privileges. IMHO "confirmed" means
"confirmed by some else".

Seeing so much consensus I'm confident that we'll reach "lazy consensus"
by next monday (2012/9/19 + 72h) and I volunteer to change the behavior
then.

So please speak up now if you disagree with the opinion that the extra
step to the "confirmed" status is an idea that does benefit the quality
of our project.

Herbert

+1

Just for the record, is this as simple as removing the check-mark from
one entry in BZ > Administration > Bug Status Workflow ?

From a testing standpoint having the policy that a "confirmed" status means that another member has reproduced the problem (eventually on another platform) means more testing effort by some factor. That may have a positive or a negative effect on the quality.

Another possibility could be that a reporter with can-confirm karma feels confident enough can set the status to confirmed himself/herself. Having to do an extra step could be sufficient for our goals.

Coming back to your question: Yes, from the admin standpoint the requested change is as simple as switching a bit. An eventual multiplication of the testing effort is worth some consideration though and "just switching bits because it is easy" shouldn't be done without having reached some consensus on this topic.

Herbert

Reply via email to