Re-introducing "UNCONFIRMED" state to bugzilla

List overview All Threads
Download

newer

older

Mark Hershberger departing...

Deadline for Wikimania submissions...

mah＠wikimedia.org

9 Mar 2012 9 Mar '12

8:16 p.m.

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state. Next week, I plan to begin recruiting volunteers for the "Bug Squad", who will help me to verify bugs by testing them against the Beta cluster. The plan is that the Bug Squad will be able to verify these bugs and change them to the "NEW" state. The Bug Squad idea comes from KDE's Bug Squad (http://techbase.kde.org/Contribute/Bugsquad) and I've begun talking with them. If you have an interest in helping out with or participating in the Bug Squad, please contact me. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

Show replies by date

Tomasz Finc

12 Mar 12 Mar

4:02 p.m.

Keep in mind that MediaWiki isn't the only software that we write. We already have a healthy beta group of Android and iOS testers. Perhaps some of them might want to be part of a bug squad team. --tomasz On Fri, Mar 9, 2012 at 5:16 PM, Mark A. Hershberger <mah(a)wikimedia.org> wrote:

...

mah＠wikimedia.org

8:48 p.m.

Tomasz Finc <tfinc(a)wikimedia.org> writes:

...

Keep in mind that MediaWiki isn't the only software that we write. We already have a healthy beta group of Android and iOS testers. Perhaps some of them might want to be part of a bug squad team.

I like the idea... Could you reply to my email titled "Bug Squad -- Activate"?? Mark. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

mah＠wikimedia.org

8:46 p.m.

New subject: Bug Squad -- Activate

As promised (and with a lot of help from Greg Varnum), I set up the Bug Squad WikiProject: https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad As of this writing, we still need to get some graphics up, but it is a start and has the beginnings of a plan of action. You can sign up now! I like Tomasz's idea of having mobile-focused bug squad activities. I'd like to get input on how to do this. Because I think it will work best with a low barrier to entry (an area where the KDE bug squad runs into problems), and because the mobile team is running on top of PhoneGap (http://phonegap.com/), I wonder if we couldn't set up a labs instance of the PhoneGap interface. Tomasz, if we are able to do that, would that allow Bug Squad members to find some bugs without starting up an emulator? -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

Tomasz Finc

13 Mar 13 Mar

10:58 p.m.

New subject: Bug Squad -- Activate

On Mon, Mar 12, 2012 at 5:46 PM, Mark A. Hershberger <mah(a)wikimedia.org> wrote: [...]

...

I like Tomasz's idea of having mobile-focused bug squad activities. I'd like to get input on how to do this. Because I think it will work best with a low barrier to entry (an area where the KDE bug squad runs into problems), and because the mobile team is running on top of PhoneGap (http://phonegap.com/), I wonder if we couldn't set up a labs instance of the PhoneGap interface.

Seems simple to build a vm that would just start up the VM and uses ant to build the app. Who's interested in taking this on?

...

Tomasz, if we are able to do that, would that allow Bug Squad members to find some bugs without starting up an emulator?

That would remove the need for them to run it locally. Eventually you might even be able to open the whole app within in a browser. --tomasz

Lars Aronsson

4:39 a.m.

On 03/10/2012 02:16 AM, Mark A. Hershberger wrote:

...

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

This has the unwanted effect that when I click "My Bugs", in the left menu on https://bugzilla.wikimedia.org/ I don't see my bugs, because it only shows "NEW", ASSIGNED, and REOPENED, but not UNCONFIRMED. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

Antoine Musso

5:43 a.m.

Le 13/03/12 09:39, Lars Aronsson a écrit :

...

On 03/10/2012 02:16 AM, Mark A. Hershberger wrote:

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

Bug 35192 opened : https://bugzilla.wikimedia.org/35192 -- Antoine "hashar" Musso

Antoine Musso

5:46 a.m.

Le 10/03/12 02:16, Mark A. Hershberger a écrit :

...

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

While we are at it, we could even use the Bugzilla 4 default workflow: http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html It is not changing that much though.

...

Next week, I plan to begin recruiting volunteers for the "Bug Squad", who will help me to verify bugs by testing them against the Beta cluster. The plan is that the Bug Squad will be able to verify these bugs and change them to the "NEW" state.

A bug squad is a great idea. We often end up with bugs that we can not reproduce or for which we have no clear consensus. -- Antoine "hashar" Musso

mah＠wikimedia.org

7:42 a.m.

Antoine Musso <hashar+wmf(a)free.fr> writes:

...

While we are at it, we could even use the Bugzilla 4 default workflow: http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html It is not changing that much though.

I've tried to copy this. In order to do this, I had to tighten up the "canconfirm" group. I added @wikimedia.org addresses and admin users to the group. Let me know of any others you think should be there. Mark.

Liangent

9:38 a.m.

On Tue, Mar 13, 2012 at 7:42 PM, Mark A. Hershberger <mah(a)wikimedia.org> wrote:

...

Antoine Musso <hashar+wmf(a)free.fr> writes:

While we are at it, we could even use the Bugzilla 4 default workflow: http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html It is not changing that much though.

Plus people with commit or labs access?

...

Mark. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-Liangent

mah＠wikimedia.org

12:05 p.m.

Liangent <liangent(a)gmail.com> writes:

...

On Tue, Mar 13, 2012 at 7:42 PM, Mark A. Hershberger <mah(a)wikimedia.org> wrote:

Plus people with commit or labs access?

So, I can use USERINFO files for people with commit access. What can I use for those with labs access? -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

K. Peachey

5:44 p.m.

Why is it even restricted? We don't restrict closing bugs.

Happy Melon

6:57 p.m.

On 13 March 2012 21:44, K. Peachey <p858snake(a)gmail.com> wrote:

...

Why is it even restricted? We don't restrict closing bugs.

As the rising tide of bugspam demonstrates, we *should*. --HM

Strainu

14 Mar 14 Mar

8:29 a.m.

În data de 10 martie 2012, 03:16, Mark A. Hershberger <mah(a)wikimedia.org> a scris:

...

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

Does this also applies to site requests? I think it shouldn't, because these have usually been discussed extensively on the wikis. Strainu

Helder

11:50 a.m.

On Wed, Mar 14, 2012 at 09:29, Strainu <strainu10(a)gmail.com> wrote:

...

În data de 10 martie 2012, 03:16, Mark A. Hershberger <mah(a)wikimedia.org> a scris:

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

Does this also applies to site requests? I think it shouldn't, because these have usually been discussed extensively on the wikis.

Makes sense. Helder

Daniel Friesen

3 p.m.

On Wed, 14 Mar 2012 07:50:38 -0800, Helder <helder.wiki(a)gmail.com> wrote:

...

On Wed, Mar 14, 2012 at 09:29, Strainu <strainu10(a)gmail.com> wrote:

În data de 10 martie 2012, 03:16, Mark A. Hershberger <mah(a)wikimedia.org> a scris:

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

Does this also applies to site requests? I think it shouldn't, because these have usually been discussed extensively on the wikis.

Makes sense. Helder

Don't we get a few site request bugs from users that haven't actually got community concensus on them? How about starting them as UNCONFIRMED. Then switching them to new when someone's verified there is a concensus on them. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Antoine Musso

3:03 p.m.

Le 14/03/12 13:29, Strainu a écrit :

...

<mah(a)wikimedia.org> a scris:

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

Does this also applies to site requests? I think it shouldn't, because these have usually been discussed extensively on the wikis.

^^^^^^^ Usually. Since sometime we have to ask for a proof of consensus, I would prefer we keep the unconfirmed state :-] We can probably still move a bug from unconfirmed to resolved so it is not going to slow down site requests. -- Antoine "hashar" Musso

Dan Collins

3:27 p.m.

On Wed, Mar 14, 2012 at 3:03 PM, Antoine Musso <hashar+wmf(a)free.fr> wrote:

...

Le 14/03/12 13:29, Strainu a écrit :

<mah(a)wikimedia.org> a scris:

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

Does this also applies to site requests? I think it shouldn't, because these have usually been discussed extensively on the wikis.

^^^^^^^ Usually. Since sometime we have to ask for a proof of consensus, I would prefer we keep the unconfirmed state :-]

Agreed. Here, "confirmation" is not that the problem exists but that the site request is: 1) Coherent 2) Something we actually do 3) Has support of the community And hopefully bugs can be closed directly from unconfirmed to INVALID or RESO LATER if it is found that the request either makes no sense whatsoever, or if there is no consensus. -- Dan

Dan Collins

2:42 p.m.

On Fri, Mar 9, 2012 at 8:16 PM, Mark A. Hershberger <mah(a)wikimedia.org> wrote:

...

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

Is it possible to configure it so that reports from developers start in the "NEW" state: https://bugzilla.wikimedia.org/show_bug.cgi?id=35225 and others -- Dan

Thomas Gries

6:13 p.m.

Am 14.03.2012 19:42, schrieb Dan Collins:

...

On Fri, Mar 9, 2012 at 8:16 PM, Mark A. Hershberger <mah(a)wikimedia.org> wrote:

I set up Bugzilla today so that, by default, bugs would be in the "UNCONFIRMED" state.

Is it possible to configure it so that reports from developers start in the "NEW" state: https://bugzilla.wikimedia.org/show_bug.cgi?id=35225 and others

+1 YESSSSSS, PLEASE

mah＠wikimedia.org

10:14 p.m.

Thomas Gries <mail(a)tgries.de> writes:

...

Am 14.03.2012 19:42, schrieb Dan Collins:

Is it possible to configure it so that reports from developers start in the "NEW" state: https://bugzilla.wikimedia.org/show_bug.cgi?id=35225 and others

+1 YESSSSSS, PLEASE

I'll add committers to the people in "canconfirm" tomorrow. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

Michael Movchin

15 Mar 15 Mar

3:14 a.m.

That means users in group "canconfirm" are able to create bugs with the state "New", not "unconfirmed". -- Michael Movchin (mmovchin) Am 15.03.2012 um 03:14 schrieb mah(a)wikimedia.org (Mark A. Hershberger):

...

Thomas Gries <mail(a)tgries.de> writes:

Am 14.03.2012 19:42, schrieb Dan Collins:

Is it possible to configure it so that reports from developers start in the "NEW" state: https://bugzilla.wikimedia.org/show_bug.cgi?id=35225 and others

+1 YESSSSSS, PLEASE

I'll add committers to the people in "canconfirm" tomorrow. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Rob Lanphier

2:29 p.m.

Mark and I just discussed this, and he's going to look into having a "CONFIRMED" state. The flow would be: "NEW"->"CONFIRMED" ...rather than: "UNCONFIRMED"->"NEW" That would also mean that all of the currently "NEW" bugs are presumed to be unconfirmed rather than confirmed, and that we can have a relatively clean list of bugs that someone explicitly declared to be confirmed. Rob On Fri, Mar 9, 2012 at 5:16 PM, Mark A. Hershberger <mah(a)wikimedia.org> wrote:

...

Michael Movchin

2:47 p.m.

Like this idea! +1 -- mmovchin (Michael Movchin) Am 15.03.2012 19:29, schrieb Rob Lanphier:

...

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

mah＠wikimedia.org

7:52 p.m.

Rob Lanphier <robla(a)wikimedia.org> writes:

...

Mark and I just discussed this, and he's going to look into having a "CONFIRMED" state.

https://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-defa… describes this implementation: UNCONFIRMED -> CONFIRMED -> IN_PROGRESS -> RESOLVED -> VERIFIED Since "UNCONFIRMED" is used so many places, I'm worried about changing that to "NEW". Bugzilla 4 should have had this upgrade script run when it was installed. Does this workflow (+ changing all "NEW" to "UNCONFIRMED") look acceptable to everyone? Mark. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

MZMcBride

9:14 p.m.

Mark A. Hershberger wrote:

...

Does this workflow (+ changing all "NEW" to "UNCONFIRMED") look acceptable to everyone?

I don't really understand the purpose of the "unconfirmed" state other than to create additional bugspam and bureaucracy. A _constant_ issue in Bugzilla is that a bug is filed and then nobody comments on it or does any follow-up with the bug filer until _years_ later. This is the problem that I think you're trying to address? I'm still not quite sure, but I'll assume it is. I don't see how adding more drop-down menu options and layers of process is going to help mitigate the underlying issue. The solution is to respond to bugs in a more timely manner with comments and follow-up and attempts to illicit steps to reproduce. MZMcBride

Krinkle

16 Mar 16 Mar

12:31 a.m.

On Mar 16, 2012, at 12:52 AM, Mark A. Hershberger wrote:

...

Rob Lanphier <robla(a)wikimedia.org> writes:

Mark and I just discussed this, and he's going to look into having a "CONFIRMED" state.

So up until last month we had this workflow: 1. NEW 2. ASSIGNED[1] 3. RESOLVED (sometimes) 4. VERIFIED (or) REOPENED -> step 1 I understand that last week it changed to: 1. UNCONFIRMED 2. NEW 3. ASSIGNED 4. RESOLVED (sometimes) 5. VERIFIED (or) REOPENED -> step 2 I don't think it makes sense to use "NEW" as "CONFIRMED", because, agreeing with [2], "NEW" is not descriptive. How about using "CONFIRMED" and dropping "NEW" completely? -- Krinkle [1] The difference between a confirmed bug having an assignee and status ASSIGNED, is that ASSIGNED means someone has it on his agenda to actively work on. Whereas the assignee in general is just whoever is currently watching over it. ASSIGNED and IN_PROGRESS are basically there same. Except that "IN_PRORESS" is slightly later than ASSIGNED but using both doesn't make sense and we're already using ASSIGNED. [2] https://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-defa… [3] http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html

Antoine Musso

3:42 a.m.

Le 16/03/12 00:52, Mark A. Hershberger a écrit :

...

UNCONFIRMED -> CONFIRMED -> IN_PROGRESS -> RESOLVED -> VERIFIED

No more NEW state :-) -- Antoine "hashar" Musso

4421

days inactive

4427

days old

wikitech-l@lists.wikimedia.org

Manage subscription

27 comments

16 participants

tags (0)

participants (16)

Antoine Musso
Dan Collins
Daniel Friesen
Happy Melon
Helder
K. Peachey
Krinkle
Lars Aronsson
Liangent
mah＠wikimedia.org
Michael Movchin
MZMcBride
Rob Lanphier
Strainu
Thomas Gries
Tomasz Finc