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.
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@wikimedia.org wrote:
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@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Tomasz Finc tfinc@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.
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?
On Mon, Mar 12, 2012 at 5:46 PM, Mark A. Hershberger mah@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
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.
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.
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.
Bug 35192 opened : https://bugzilla.wikimedia.org/35192
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 Musso hashar+wmf@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.
On Tue, Mar 13, 2012 at 7:42 PM, Mark A. Hershberger mah@wikimedia.org wrote:
Antoine Musso hashar+wmf@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.
Plus people with commit or labs access?
Mark.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-Liangent
Liangent liangent@gmail.com writes:
On Tue, Mar 13, 2012 at 7:42 PM, Mark A. Hershberger mah@wikimedia.org wrote:
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.
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?
On 13 March 2012 21:44, K. Peachey p858snake@gmail.com wrote:
Why is it even restricted? We don't restrict closing bugs.
As the rising tide of bugspam demonstrates, we *should*.
--HM
În data de 10 martie 2012, 03:16, Mark A. Hershberger mah@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
On Wed, Mar 14, 2012 at 09:29, Strainu strainu10@gmail.com wrote:
În data de 10 martie 2012, 03:16, Mark A. Hershberger mah@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
On Wed, 14 Mar 2012 07:50:38 -0800, Helder helder.wiki@gmail.com wrote:
On Wed, Mar 14, 2012 at 09:29, Strainu strainu10@gmail.com wrote:
În data de 10 martie 2012, 03:16, Mark A. Hershberger mah@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.
Le 14/03/12 13:29, Strainu a écrit :
mah@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.
On Wed, Mar 14, 2012 at 3:03 PM, Antoine Musso hashar+wmf@free.fr wrote:
Le 14/03/12 13:29, Strainu a écrit :
mah@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
On Fri, Mar 9, 2012 at 8:16 PM, Mark A. Hershberger mah@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
Am 14.03.2012 19:42, schrieb Dan Collins:
On Fri, Mar 9, 2012 at 8:16 PM, Mark A. Hershberger mah@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
Thomas Gries mail@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.
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@wikimedia.org (Mark A. Hershberger):
Thomas Gries mail@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@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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@wikimedia.org wrote:
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@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Like this idea! +1
-- mmovchin (Michael Movchin)
Am 15.03.2012 19:29, schrieb Rob Lanphier:
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. Hershbergermah@wikimedia.org wrote:
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@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Rob Lanphier robla@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-defau...
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 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
On Mar 16, 2012, at 12:52 AM, Mark A. Hershberger wrote:
Rob Lanphier robla@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-defau...
describes this implementation:
UNCONFIRMED -> CONFIRMED -> IN_PROGRESS -> RESOLVED -> VERIFIED
Since "UNCONFIRMED" is used so many places, I'm worried about changing that to "NEW".
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-defau... [3] http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
wikitech-l@lists.wikimedia.org