[Wikitech-l] The bugtracker problem, again

[David Gerard]

Discussion on Oliver Keyes' blog:

http://quominus.org/archives/714

He's coming from the perspective of liaison with newbies. Read the comments.

(I will note that Antoine Musso was right in the previous discussion
that Mantis has a nice, friendly interface. I myself was most
displeased to discover that (a) the code itself is really horrible (b)
it's all but unsupported even to free-software standards.)


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Mark A. Hershberger]

David Gerard  writes:

> It occurred to me "wouldn't it be nice if Linus Torvalds had decided
> he really needed bug tracking done right and written a solution". He
> didn't write a solution, but he did rant:
>
> http://yarchive.net/comp/linux/bug_tracking.html

You do not want Linus Torvalds writing tools meant for end users.  One
only has to look at the struggles our development community (a technical
audience, to be sure) has with using git to see the truth in this.

Linus is a very smart man, but this does not mean he is the right person
to design a bug tracking tool for end users.

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Mark A. Hershberger]

MZMcBride  writes:

> Mark H. and I have had previous discussions about generally improving user
> feedback tools.

I haven't stopped thinking about these and even discussed it some with
Summana last week.

> Even if it just guided the user to the appropriate place. Help wizard,
> maybe?

I was thinking along these lines and, in the spirit of getting
*something* started, just started at the first step:

https://www.mediawiki.org/wiki/Bug_management/Workflow

Since I mostly deal with Bugzilla, I'm most familiar with that.  Someone
turned up this page last week:

https://bugzilla.wikimedia.org/enter_bug.cgi?product=Tools&format=guided

I plan on looking at this and the other work Mozilla has done to see if
it would be useful.

-- 
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
m...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Oliver Keyes]

On Mon, May 14, 2012 at 4:46 PM, Diederik van Liere wrote:

> I don't think we should aim to cater to non-developers at all. The changes
> that a non-developer finds a real bug are very very small (in my previous
> life as an academic I have done a lot of research on Bugzilla and developer
> productivity and it's based on that experience that I am making this
> statement). I think that if a newbie / non-developer finds bugzilla then he
> /she should be redirected to either IRC / Teahouse / Talk pages / FAQ or
> any other support channel that we have. They can always be send back to
> file a bug report.
>
> I'm not questioning your experiences in development overall, but in the
specific context of Wikimedia I've found a big pile o'bugs through user
intervention. With New Page Triage/New Pages Feed alone, 16 bugs and
enhancements were identified in the first 24 hours, all from non-technical
editors. That number has continued to grow - again, from non-technical
users.

If we direct them to other support channels, the bug *still* has to end up
in bugzilla. The only difference is we're relying on developers, technical
users, the bugmeister and others to constantly monitor and look at a
plethora of channels and report things, which'll suck in their time and add
another link to the chain. Every time you add relays, data gets lost.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Andre Klapper]

Hi,

On Mon, 2012-05-14 at 04:55 +0200, Krinkle wrote:
> Assignee should be empty by default, only set when going to be worked on.
> Current "Default assignee" should in most cases be default CC. Then we won't
> need status "ASSIGNED" anymore (which is currently often forgotten, but due to
> the "default assignee" stuff, one can often not see whether it's really on
> someone's list).

1) From a (slighly egoistic) bugmaster point of view I prefer to not
edit the default CC list everytime somebody changes her/his field of
interest or joins or leaves the project.
2) As far as I understand I am currently unable to follow development
(means: all bugmail) for a specific component or product that interests
me as a volunteer / potential future contributor.
Somebody please correct me if I am wrong.

In GNOME Bugzilla we "worked around" both problems by abusing the
"Default QA Contact" field (which is not enabled in Wikimedia Bugzilla):
We use a fake account specific for each component 
(e.g. "NOBODY <$component-ow...@wikimedia.bugs>" as default QA contact
for $component AND as default assignee).
Developers and interested volunteers can add this account to their
"Bugzilla user watchlist" to receive all bugmail for that component.
The real name makes clear that "nobody" is assigned to work on the task.
If $somebody plans to work on a task you can set the assignee to
$somebody, and anybody else can still follow the progress of that task
as the QA Contact is still that fake email address in his/her watchlist.

FYI, I filed this idea as
https://bugzilla.wikimedia.org/show_bug.cgi?id=36457

andre
-- 
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Daniel Andre]

In the bug genie, we've added functionality called "teams" to address these
kind of needs. Anyone can be a member of any number of teams, and teams can
be assigned to almost all the fields a user can, such as
"owner"/"assignee", etc. This goes for both issues, projects, components
and more. This makes managing users joining and leaving much easier, as
well as monitoring and subscribing to updates on interesting
topics/components.

I think at least Redmine also has something similar.

-Daniel André
On Tue, May 15, 2012 at 1:35 PM, Andre Klapper wrote:

> Hi,
>
> On Mon, 2012-05-14 at 04:55 +0200, Krinkle wrote:
> > Assignee should be empty by default, only set when going to be worked on.
> > Current "Default assignee" should in most cases be default CC. Then we
> won't
> > need status "ASSIGNED" anymore (which is currently often forgotten, but
> due to
> > the "default assignee" stuff, one can often not see whether it's really
> on
> > someone's list).
>
> 1) From a (slighly egoistic) bugmaster point of view I prefer to not
> edit the default CC list everytime somebody changes her/his field of
> interest or joins or leaves the project.
> 2) As far as I understand I am currently unable to follow development
> (means: all bugmail) for a specific component or product that interests
> me as a volunteer / potential future contributor.
> Somebody please correct me if I am wrong.
>
> In GNOME Bugzilla we "worked around" both problems by abusing the
> "Default QA Contact" field (which is not enabled in Wikimedia Bugzilla):
> We use a fake account specific for each component
> (e.g. "NOBODY <$component-ow...@wikimedia.bugs>" as default QA contact
> for $component AND as default assignee).
> Developers and interested volunteers can add this account to their
> "Bugzilla user watchlist" to receive all bugmail for that component.
> The real name makes clear that "nobody" is assigned to work on the task.
> If $somebody plans to work on a task you can set the assignee to
> $somebody, and anybody else can still follow the progress of that task
> as the QA Contact is still that fake email address in his/her watchlist.
>
> FYI, I filed this idea as
> https://bugzilla.wikimedia.org/show_bug.cgi?id=36457
>
> andre
> --
> Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
> http://blogs.gnome.org/aklapper/
>
>
> ___
> 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

Re: [Wikitech-l] The bugtracker problem, again

[Mark A. Hershberger]

Andre Klapper  writes:

> 2) As far as I understand I am currently unable to follow development
> (means: all bugmail) for a specific component or product that interests
> me as a volunteer / potential future contributor.
> Somebody please correct me if I am wrong.

You can have yourself (or a mail alias) added as the default CC for a
component.

Using mail aliases on the default CC list would be similar to Daniel
Andre's description of Bug Genie's "teams".

-- 
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
m...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Andre Klapper]

On Tue, 2012-05-15 at 09:33 -0400, Mark A. Hershberger wrote:
> Andre Klapper  writes:
> 
> > 2) As far as I understand I am currently unable to follow development
> > (means: all bugmail) for a specific component or product that interests
> > me as a volunteer / potential future contributor.
> > Somebody please correct me if I am wrong.
> 
> You can have yourself (or a mail alias) added as the default CC for a
> component.

Can I (average user) add myself to that default CC list for a component
(I am not aware of any way), or do I need to first need to find out that
"default CC" exists, somehow find out who and how to contact for getting
added to it (and then somebody has to add me and respond to my request)
without losing motivation on my way to achieve all this? :-/

andre
-- 
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Chad]

On Sun, May 13, 2012 at 10:55 PM, Krinkle  wrote:
> TL;DR: Reduce number of fields in our BugZilla. Simplify access to search 
> filters.
>
> [snip]
>
> I'm convinced all other fields can be done without and removing them will
> improve the workflow of the developers and the Bugmeister. Including, but not
> limited to:
> - Platform (Hardware/OS)
>

I agree on platform. As an example, I decided to take a look at
the bugs set with Platform = HP this morning.

There were 31 bugs with this platform set. Most had the OS set
to Windows, so what they really meant as the platform is a PC
(HP in this case refers to HP servers/mainframes). Several more
were definitely bugs that applied to All platforms. There were only
about 3 or 4 that were actually applying to HP-specific hardware
issues that weren't PCs. Since this value seems to be so unused
(and largely misused), I recategorized these 31 bugs and deleted
HP from the platform field.

A small victory, I suppose.

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Martijn Hoekstra]

On Tue, May 15, 2012 at 4:31 PM, Chad  wrote:
> On Sun, May 13, 2012 at 10:55 PM, Krinkle  wrote:
>> TL;DR: Reduce number of fields in our BugZilla. Simplify access to search 
>> filters.
>>
>> [snip]
>>
>> I'm convinced all other fields can be done without and removing them will
>> improve the workflow of the developers and the Bugmeister. Including, but not
>> limited to:
>> - Platform (Hardware/OS)
>>
>
> I agree on platform. As an example, I decided to take a look at
> the bugs set with Platform = HP this morning.
>
> There were 31 bugs with this platform set. Most had the OS set
> to Windows, so what they really meant as the platform is a PC
> (HP in this case refers to HP servers/mainframes). Several more
> were definitely bugs that applied to All platforms. There were only
> about 3 or 4 that were actually applying to HP-specific hardware
> issues that weren't PCs. Since this value seems to be so unused
> (and largely misused), I recategorized these 31 bugs and deleted
> HP from the platform field.
>
> A small victory, I suppose.
>
> -Chad

Wut, there are MediaWiki installations runing on HP-UX? And we have
developers equipped to work on bugs for that platform?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Platonides]

On 14/05/12 18:19, Risker wrote:
> Martijn is on to something here.  I write as a non-developer who has
> identified bugs and has been pressed to report them via Bugzilla, despite
> the fact that I feel very much out of my depth there.  For those of us who
> can report problems but not solve them (other than to test solutions), a
> simpler process would probably help to ensure that the bugs are reported in
> a more standard way that is most likely to be useful to the developer team.

This is a good point.
I sometimes get a bug discussed through irc, and I may end up asking:
can you report that in bugzilla?

Doing it that way has a number of benefits:
- The bug is explained by the original reporter, not as
viewed/understood by a second-person.
- It provides a source of request for the change.
- The reporter can get feedback about the status (eg. it got reverted).
- Even if the people who initially dealt with it doesn't follow with the
problem, it gets registered.
- Further questions go directly to the reporter, no need to have them
proxied to the Village Pump.


So I get convinced on having bugzilla at least barely usable for end
users. :-)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Antoine Musso]

Le 15/05/12 16:43, Martijn Hoekstra a écrit :

> Wut, there are MediaWiki installations runing on HP-UX? And we have
> developers equipped to work on bugs for that platform?

It is not that much a problem. You have the full suite of GNU tools
packaged for HP-UX as well as most popular OSS (Apache, PHP, vim ..).



-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Mark A. Hershberger]

Krinkle  writes:

> TL;DR: Reduce number of fields in our BugZilla. Simplify access to
> search filters.

I talked for a bit about this with Krinkle today.  I think part of the
problem with the complexity of the fields (and, yes, Bugzilla fields are
too complicated) comes from the different roles people have when they
come to Bugzilla.  Making Bugzilla work for everyone means a bit of
complexity.  Work can certainly be done on the UI to help alleviate
this, but I think understanding the different perspectives is a first
step to working on the UI.

I see three different ways of looking at the data in Bugzilla:

Developer -- What can I work on right now?  What is the next think on my
list of TODOs?  Where can I put items that need to be worked on
later?

Director/Manager -- What set of work needs to get done before my next
release?  What is blocking my next deliverable?  For feature X, what
are the different things that need to be implemented?

End User/Bugmeister -- How can I report current problems?  Where can I
track progress on the resolution of a problem I'm interested in?
How can I make sure people with the power to fix the problem are
aware of its severity and impact?

With these three views of Bugzilla in mind the Developer is going to be
looking for the next action item.

The Developer works with the Director to help the Director develop
reasonable timelines.  Bugzilla's Milestones and the priority within a
Milestone are especially suited for this.

The Director looks at the features that the team needs to deliver and
the issues the Bugmeister has raised and works to prioritize the issues
relative to the project.

The Bugmeister looks at incoming bug reports (both in Bugzilla and on
Village Pumps) and makes sure that urgent issues are addressed quickly,
while less urgent issues are properly prioritized.  The Bugmeister does
not set schedules or deliverables, but needs a way to raise issues and
act as an advocate for the End User.  The priority and severity fields
are especially suited for this.

I do think the UI of Bugzilla needs work and I plan to begin addressing
some of the issues this week.  But I also think there is a good reason
to track the data that is tracked.



-- 
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
m...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Tomasz Finc]

On Mon, May 21, 2012 at 2:25 PM, Mark A. Hershberger  wrote:
> The Developer works with the Director to help the Director develop
> reasonable timelines.  Bugzilla's Milestones and the priority within a
> Milestone are especially suited for this.

We tried the milestones and they were worse then tracking bugs.
Sharing urls like this

https://bugzilla.wikimedia.org/buglist.cgi?list_id=117138&resolution=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&target_milestone=1.2%20release&product=Wikipedia%20App

vs

https://bugzilla.wikimedia.org/show_bug.cgi?id=36745 is a pain. You
could save the search but then its only available to you. Quickly
seeing what's resolved/blocking your release without having to go back
to advanced search is key.

CC'ing Yuvi so that he can provide more context

We'll be switching away from milestones and back to tracking bugs for
the next app release.

--tomasz

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Roan Kattouw]

On Mon, May 21, 2012 at 3:17 PM, Tomasz Finc  wrote:
> On Mon, May 21, 2012 at 2:25 PM, Mark A. Hershberger  
> wrote:
>> The Developer works with the Director to help the Director develop
>> reasonable timelines.  Bugzilla's Milestones and the priority within a
>> Milestone are especially suited for this.
>
> We tried the milestones and they were worse then tracking bugs.
> Sharing urls like this
>
> https://bugzilla.wikimedia.org/buglist.cgi?list_id=117138&resolution=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&target_milestone=1.2%20release&product=Wikipedia%20App
>
> vs
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=36745 is a pain. You
> could save the search but then its only available to you. Quickly
> seeing what's resolved/blocking your release without having to go back
> to advanced search is key.
>
You can share your saved searches. I don't remember how it's done, but
I seem to have searches in my list that were shared by Antoine and
Sumana. Example URL:
https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Day%20old%20patches&sharer_id=11475&list_id=117143

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Chad]

Yeah but its a PITA.

-Chad
On May 21, 2012 6:25 PM, "Roan Kattouw"  wrote:

> On Mon, May 21, 2012 at 3:17 PM, Tomasz Finc  wrote:
> > On Mon, May 21, 2012 at 2:25 PM, Mark A. Hershberger 
> wrote:
> >> The Developer works with the Director to help the Director develop
> >> reasonable timelines.  Bugzilla's Milestones and the priority within a
> >> Milestone are especially suited for this.
> >
> > We tried the milestones and they were worse then tracking bugs.
> > Sharing urls like this
> >
> >
> https://bugzilla.wikimedia.org/buglist.cgi?list_id=117138&resolution=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&target_milestone=1.2%20release&product=Wikipedia%20App
> >
> > vs
> >
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=36745 is a pain. You
> > could save the search but then its only available to you. Quickly
> > seeing what's resolved/blocking your release without having to go back
> > to advanced search is key.
> >
> You can share your saved searches. I don't remember how it's done, but
> I seem to have searches in my list that were shared by Antoine and
> Sumana. Example URL:
>
> https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Day%20old%20patches&sharer_id=11475&list_id=117143
>
> Roan
>
> ___
> 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

Re: [Wikitech-l] The bugtracker problem, again

[Tomasz Finc]

+1  If you guys can make it work then let the mobile team know.
Otherwise were sticking with what works for us.

--tomasz


On Mon, May 21, 2012 at 3:35 PM, Chad  wrote:
> Yeah but its a PITA.
>
> -Chad
> On May 21, 2012 6:25 PM, "Roan Kattouw"  wrote:
>
>> On Mon, May 21, 2012 at 3:17 PM, Tomasz Finc  wrote:
>> > On Mon, May 21, 2012 at 2:25 PM, Mark A. Hershberger 
>> wrote:
>> >> The Developer works with the Director to help the Director develop
>> >> reasonable timelines.  Bugzilla's Milestones and the priority within a
>> >> Milestone are especially suited for this.
>> >
>> > We tried the milestones and they were worse then tracking bugs.
>> > Sharing urls like this
>> >
>> >
>> https://bugzilla.wikimedia.org/buglist.cgi?list_id=117138&resolution=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&target_milestone=1.2%20release&product=Wikipedia%20App
>> >
>> > vs
>> >
>> > https://bugzilla.wikimedia.org/show_bug.cgi?id=36745 is a pain. You
>> > could save the search but then its only available to you. Quickly
>> > seeing what's resolved/blocking your release without having to go back
>> > to advanced search is key.
>> >
>> You can share your saved searches. I don't remember how it's done, but
>> I seem to have searches in my list that were shared by Antoine and
>> Sumana. Example URL:
>>
>> https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Day%20old%20patches&sharer_id=11475&list_id=117143
>>
>> Roan
>>
>> ___
>> 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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Thehelpfulone]

On 21 May 2012 23:25, Roan Kattouw  wrote:

>
> You can share your saved searches. I don't remember how it's done, but
> I seem to have searches in my list that were shared by Antoine and
> Sumana. Example URL:
>
> https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Day%20old%20patches&sharer_id=11475&list_id=117143
>
>
Try  https://bugzilla.wikimedia.org/userprefs.cgi?tab=saved-searches - you
want to share with a group "editbugs" as this is the user group that all
users are put into.

-- 
Thehelpfulone
http://meta.wikimedia.org/wiki/User:Thehelpfulone
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Thehelpfulone]

On 22 May 2012 00:26, Thehelpfulone  wrote:

> Try  https://bugzilla.wikimedia.org/userprefs.cgi?tab=saved-searches -
>> you want to share with a group "editbugs" as this is the user group that
>> all users are put into.
>
>
I thought all users had editbugs, but there are 15525 users in total and
14573 users in the editbugs group. I imagine this right assigning must be
automatic, so does anyone know why there's a discrepancy between those
numbers?

-- 
Thehelpfulone
http://meta.wikimedia.org/wiki/User:Thehelpfulone
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[K. Peachey]

We don't assign that group automatically anymore by default afaik.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Krinkle]

On May 22, 2012, at 12:17 AM, Tomasz Finc wrote:

> We tried the milestones and they were worse then tracking bugs.
> Sharing urls like this
> 
> https://bugzilla.wikimedia.org/buglist.cgi?list_id=117138&resolution=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&target_milestone=1.2%20release&product=Wikipedia%20App
> 
> vs
> 
> https://bugzilla.wikimedia.org/show_bug.cgi?id=36745 is a pain. You
> could save the search but then its only available to you. Quickly
> seeing what's resolved/blocking your release without having to go back
> to advanced search is key.
> 


The findability of such url is important, but the length or prettyness should
imho not be a factor. One could even argue that the longer one is actually more
usable because it contains the relevant product and version (rather than a
seemingly arbitrary bug ID) - and makes it possible to manipulate or construct
the url by hand (whether or not assisted by autocompletion in the address bar).

We can build portals, share bookmarks, create wiki pages with links, customize
the bugzilla sidebar, set links as default search for everybody and what not,
use shortcuts in mw-bot/wm-bot, shorten them with a url-shortener to a human
memorable url (e.g. http://tinyurl.com/mw-12-open  ). Lots of options for 
sharing. 

Also, for MediaWiki core we're going more and more towards rolling releases.
Bugs and features will be scheduled and prioritized, but it is rare for
something to truly block a release. Sure we can schedule a feature for a
version, but if we don't make it, the release cycle will likely overrule the
feature implementation (or bug fix) and the bug is re-scheduled (depending on
why it wasn't done it will probably be moved to the next release, wontfixed
or perhaps left unscheduled until there is more interest or an assignee
available).

For myself I created a little portal to make working with our current workflow
easy (for MediaWiki core that is).
https://toolserver.org/~krinkle/wmfBugZillaPortal/


On May 22, 2012, at 4:05 AM, Yuvi Panda wrote:

> Also, Tracking bugs let us make comments about the release itself, something 
> that milestones don't. 

Since we're going more towards rolling releases I don't think we really need
such a place for MediaWiki core releases. Meta-discussion about the use of
milestones in general doesn't belong there anyway. And neither does discussion
about the release process. So what kind of discussion would take place on a
"MediaWiki 1.X.Y release (tracking)" bug that shouldn't take place on
wikitech-l, mediawiki-l, [[mw:Talk:MediaWiki 1.X]]  or some other place?

The milestones are just the schedule / planning for developers to work from.

For scouting BugZilla I think this would be the workflow that ops and developers
follow (for BugZilla).

Developers: 
* Open bugs in components other than Wikimedia (i.e. MediaWiki core/extensions)
  scheduled for the next deployment
-> Cross-component tracker bug for 1.20wmf4: open[1]

* Open bugs scheduled for the currently being developed release
-> MediaWiki Milestone: 1.20.0 release: open[2]


Ops:
* General tasks for the current deployment (this list should be empty by the
  time deployment happens, but if things brake after deployment that need fixing
  right now, those bugs would be scheduled for the current deployment)
-> Wikimedia Milestone: 1.20wmf3: open[3]

* General tasks that need to happen before or at the next deployment window
  (this list has to be empty before deployment. Anything on there either needs 
to
  be done or re-evaluated)
-> Wikimedia Milestone: 1.20wmf4: open[4]

I'm curious whether other developers / ops also work (or would like to work)
like this though, and if not, what queries you use a lot. For example, another
way would be to work solely from searches like "Assigned to me" and rely on
someone else to use above queries and make sure everything high up, that isn't
fixed or assigned, gets assigned or lowered in priority. 

-- Krinkle

[1] [2] [3] [4] These are all linked from 
https://toolserver.org/~krinkle/wmfBugZillaPortal/

[1] https://bugzilla.wikimedia.org/showdependencytree.cgi?hide_resolved=1
[2] 
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=advanced&product=MediaWiki&target_milestone=1.20.0%20release
[3] 
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=advanced&product=Wikimedia&target_milestone=1.20wmf3%20deployment
[4] 
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=advanced&product=Wikimedia&target_milestone=1.20wmf4%20deployment
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Platonides]

On 22/05/12 01:34, Thehelpfulone wrote:
> I thought all users had editbugs, but there are 15525 users in total and
> 14573 users in the editbugs group. I imagine this right assigning must be
> automatic, so does anyone know why there's a discrepancy between those
> numbers?

It stopped being automatically given after the issues with the bugzilla
vandal (or rather, we placed existing people to the new editbugs group).


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Rob Lanphier]

On Tue, May 22, 2012 at 2:05 AM, Krinkle  wrote:
> On May 22, 2012, at 12:17 AM, Tomasz Finc wrote:
>
>> We tried the milestones and they were worse then tracking bugs.
>> Sharing urls like this
>>
>> https://bugzilla.wikimedia.org/buglist.cgi?list_id=117138&resolution=---&resolution=LATER&resolution=DUPLICATE&query_format=advanced&target_milestone=1.2%20release&product=Wikipedia%20App
>>
>> vs
>>
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=36745 is a pain. You
>> could save the search but then its only available to you. Quickly
>> seeing what's resolved/blocking your release without having to go back
>> to advanced search is key.
>
> The findability of such url is important, but the length or prettyness should
> imho not be a factor. One could even argue that the longer one is actually 
> more
> usable because it contains the relevant product and version (rather than a
> seemingly arbitrary bug ID) - and makes it possible to manipulate or construct
> the url by hand (whether or not assisted by autocompletion in the address 
> bar).

Yes, but having email readers do word wrap and truncation on URLs sucks.

Saved searches would be ideal, but someone (maybe someone here!) needs
to implement public saved searches:
https://bugzilla.mozilla.org/show_bug.cgi?id=400063

It would be really great if we could coerce Bugzilla into behaving
more like Redmine when it comes to milestones ("target versions" in
their lingo).  For example, look at this bug:
http://www.redmine.org/issues/6597

Note that the "target version" is a link to "2.1.0" (as of this
writing).  Clicking on that link, that gives me:
http://www.redmine.org/versions/47

^ That page gives me a well-organized list of issues that are
potential blockers for that release.

Now look at this:
http://www.redmine.org/projects/redmine/roadmap

That's all of their upcoming releases.  You can see at a glance what
is planned for the next release, and what hasn't yet been pegged to a
particular release.

Also, we can go back in time
http://www.redmine.org/versions/40

^ This view gives us something to possibly use for release notes.

The bar charts don't do too much for me.  I'm mainly looking at this
as a reasonably uncluttered view of what is associated with what
milestone.   Note that there are links to the same data presented in
the standard query interface.

Bugzilla has all of the data to generate the release note style view,
but someone with some Bugzilla hacking ability would need to write the
extension.  Or maybe we could write a MediaWiki extension that uses
the BZ API to generate these views.  The only kicker would be making
sure we also make the links from the individual issues actually go to
the nice views.

> Also, for MediaWiki core we're going more and more towards rolling releases.
> Bugs and features will be scheduled and prioritized, but it is rare for
> something to truly block a release. Sure we can schedule a feature for a
> version, but if we don't make it, the release cycle will likely overrule the
> feature implementation (or bug fix) and the bug is re-scheduled (depending on
> why it wasn't done it will probably be moved to the next release, wontfixed
> or perhaps left unscheduled until there is more interest or an assignee
> available).

I think I might be better about using milestones if the milestone that
I was using was reliably there.  The 1.20wmf* milestones don't appear
to be there for MediaWiki (only Wikimedia).  That makes milestone
kinda useless for deployment planning purposes.  I'm not paying
attention to the milestones now because I can't trust the queries
contain all of the information I need.

I've been holding off until we hire our Bug Wrangler before making a
fuss about this, but I imagine the next Bug Wrangler is going to want
this ability.

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Mark A. Hershberger]

Andre Klapper  writes:

> Can I (average user) add myself to that default CC list for a component
> (I am not aware of any way), or do I need to first need to find out that
> "default CC" exists, somehow find out who and how to contact for getting
> added to it (and then somebody has to add me and respond to my request)
> without losing motivation on my way to achieve all this? :-/

I just discovered the Component Watching extension for Bugzilla that allows
anyone to watch any component via their Bugzilla preferences.

https://bugzilla.mozilla.org/show_bug.cgi?id=634531

Since I think this would be very useful for Wikimedia users, I've created a
request for it:

https://bugzilla.wikimedia.org/show_bug.cgi?id=37105

-- 
http://hexmode.com/

Find peace within yourself and there will be peace on heaven and
earth.  -- Abba Isaac


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[MZMcBride]

David Gerard wrote:
> Discussion on Oliver Keyes' blog:
> 
> http://quominus.org/archives/714
> 
> He's coming from the perspective of liaison with newbies. Read the comments.
> 
> (I will note that Antoine Musso was right in the previous discussion
> that Mantis has a nice, friendly interface. I myself was most
> displeased to discover that (a) the code itself is really horrible (b)
> it's all but unsupported even to free-software standards.)

Interesting post. Can probably be summed up "technical tool doesn't work
well for non-techies." Film at 11.

Mark H. and I have had previous discussions about generally improving user
feedback tools. The Wikimedia Foundation's approach seems to largely consist
of a giant feedback bar with giant colorful faces (no, seriously:
).

My notes on a better approach to this problem are here:
. There are associated bugs
scattered around as well.

You quickly run into an issue of scope, though. What should be flagged as a
user content issue? What's a technical or software issue? What's a legal
issue? And depending on the answer, there may be vastly different areas
where to stick the issues (OTRS, a talk page, a noticeboard, reference desk,
help desk, Bugzilla, etc.). But a generic reusable feedback tool that
doesn't treat our users like retards would be cool.

Even if it just guided the user to the appropriate place. Help wizard,
maybe? Dunno.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[David Gerard]

On 12 May 2012 19:40, MZMcBride  wrote:

> You quickly run into an issue of scope, though. What should be flagged as a
> user content issue? What's a technical or software issue? What's a legal
> issue? And depending on the answer, there may be vastly different areas
> where to stick the issues (OTRS, a talk page, a noticeboard, reference desk,
> help desk, Bugzilla, etc.). But a generic reusable feedback tool that
> doesn't treat our users like retards would be cool.
> Even if it just guided the user to the appropriate place. Help wizard,
> maybe? Dunno.


This is why I suspect the real answer is someone has to write
something custom for WMF requirements (just as Bugzilla was something
custom for Netscape requirements, and has ossified in that shape). And
it'll *still* *really suck*, because all software does.


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Steven Walling]

On Sat, May 12, 2012 at 11:40 AM, MZMcBride  wrote:

> Mark H. and I have had previous discussions about generally improving user
> feedback tools. The Wikimedia Foundation's approach seems to largely
> consist
> of a giant feedback bar with giant colorful faces (no, seriously:
> ).
>
> My notes on a better approach to this problem are here:
> . There are associated
> bugs
> scattered around as well.
>

I think it's awesome that anyone is considering something to replace the
nightmare that is Bugzilla, but let me correct an inaccurate assumption you
have here:

Moodbar was not built to be a general purpose issue reporting tool. And
definitely not something that could or should replace an issue tracker. It
is designed only for asking newcomers whether they are having a generally
positive or negative experience and why, so that we could get an overall
read on the mood of new editors. Either outcome could in fact be the
product of totally normal experiences on Wikipedia.

As for the "colorful faces" you seem to dislike, well, it wasn't designed
with your demographic in mind. To date hundreds of editors are not only
successfully reporting issues, they're getting responses from other
editors: https://toolserver.org/~dartar/fd/

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[K. Peachey]

On Sun, May 13, 2012 at 4:40 AM, MZMcBride  wrote:
> Interesting post. Can probably be summed up "technical tool doesn't work
> well for non-techies." Film at 11.
>
> Mark H. and I have had previous discussions about generally improving user
> feedback tools. The Wikimedia Foundation's approach seems to largely consist
> of a giant feedback bar with giant colorful faces (no, seriously:
> ).
>
> My notes on a better approach to this problem are here:
> . There are associated bugs
> scattered around as well.
>
> You quickly run into an issue of scope, though. What should be flagged as a
> user content issue? What's a technical or software issue? What's a legal
> issue? And depending on the answer, there may be vastly different areas
> where to stick the issues (OTRS, a talk page, a noticeboard, reference desk,
> help desk, Bugzilla, etc.). But a generic reusable feedback tool that
> doesn't treat our users like retards would be cool.
>
> Even if it just guided the user to the appropriate place. Help wizard,
> maybe? Dunno.
>
> MZMcBride

The whole "post bugs to a talk page" thing with features roll outs (or
in general) really bug me and I believe i've made that view quiet well
known in several places (and I know other people share this view as
well).

As for the whole BugZilla vs Other reporting tools, I think our
primarily demographic (especially more on the MediaWiki side of this)
is more the semi technical side compared to the less technical
demographic.

Although in the last "OMG lets overthrow BugZilla and replace it with
X" mailing list thread, There were apparently some
improvements/features we could change in our installation to make it
more "friendly", If anyone ever followed up on looking at this I don't
know.


(I personally like BugZilla, Out of all the bug reporting systems i've
used as a semitechnical person, I think it has the right mix of "stuff
for unadvanced" and "stuff for advanced" users on the submission pages
[and other areas])

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[David Gerard]

On 12 May 2012 21:25, K. Peachey  wrote:

> (I personally like BugZilla, Out of all the bug reporting systems i've
> used as a semitechnical person, I think it has the right mix of "stuff
> for unadvanced" and "stuff for advanced" users on the submission pages
> [and other areas])


It's horrible, but it mostly works.

It occurred to me "wouldn't it be nice if Linus Torvalds had decided
he really needed bug tracking done right and written a solution". He
didn't write a solution, but he did rant:

http://yarchive.net/comp/linux/bug_tracking.html

We're complaining about the reporting. How is Bugzilla for connecting
developers and bugs? How do developers actually get connected to
problems? Particularly problems where the reporter isn't clear on the
component.


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[K. Peachey]

On Sun, May 13, 2012 at 6:38 AM, David Gerard  wrote:
> We're complaining about the reporting. How is Bugzilla for connecting
> developers and bugs? How do developers actually get connected to
> problems? Particularly problems where the reporter isn't clear on the
> component.

Generally a comment is made requesting more details, Which (unless
they have changed their BZ settings from the default) will email them
about the change to the ticket and include said comment.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[MZMcBride]

Steven Walling wrote:
> Moodbar was not built to be a general purpose issue reporting tool. And
> definitely not something that could or should replace an issue tracker. It
> is designed only for asking newcomers whether they are having a generally
> positive or negative experience and why, so that we could get an overall
> read on the mood of new editors. Either outcome could in fact be the
> product of totally normal experiences on Wikipedia.
> 
> As for the "colorful faces" you seem to dislike, well, it wasn't designed
> with your demographic in mind. To date hundreds of editors are not only
> successfully reporting issues, they're getting responses from other
> editors: https://toolserver.org/~dartar/fd/

I'm not following you (and I'm not sure you're following me). Wikimedia's
response to the "gather user feedback regarding the site" issue has been
MoodBar, which, regardless of the demographic I happen to sit in, looks
ridiculous. I can find a number of people from other demographics who agree.

You write that MoodBar wasn't built to be a general purpose issue reporting
tool. But you also write that hundreds of editors are successfully reporting
issues and receiving responses from other editors. Something isn't aligning
here.

As I said, a generic reusable feedback tool that doesn't treat our users
like retards would be cool. MoodBar _might_ be version 0.1 of this concept,
but it needs a lot of work.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Helder Wiki]

On Sat, May 12, 2012 at 3:40 PM, MZMcBride  wrote:
> My notes on a better approach to this problem are here:
> . There are associated bugs
> scattered around as well.

For the record, the script
https://en.wikipedia.org/wiki/MediaWiki:Wikibugs.js
was updated on other wikis but still needs to be updated on enwiki:
https://en.wikipedia.org/w/index.php?diff=prev&oldid=479666994

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Platonides]

On 12/05/12 18:17, David Gerard wrote:
> Discussion on Oliver Keyes' blog:
> 
> http://quominus.org/archives/714
> 
> He's coming from the perspective of liaison with newbies. Read the comments.

I have to say it's the first time I met him.

I'll try to summarise his points below with my comments:

1a) The steps are not clear.

Solution: Make the "Enter a new bug report" link of
https://bugzilla.wikimedia.org/ much bigger.

The intermediate page asking you to login is not "cool", but I think
that's a clear enough path.


1b) There's no indication that your login is your email.

Granted. This can be confusing. Specially for the perspective of a
mediawiki user.
The only positive point might be that, if you have recently registered,
you probably remember that your email is your login.

The email sent by bugzilla does help, although it isn't explicit, either:
> To use the wonders of Bugzilla, you can use the following:
> 
>  E-mail address: platoni...@gmail.com
>Password: HPqd4NwIu

Proposal: Add a message at the front page noting that you need a
different login for bugzilla, that it is our email, and it'll be
publicly visible.


2) You need to know the components where to file the bug.
Yes, it can be confusing.
Add a Generic group from where they should be refiled into the
appropiate component?


3a) Bugzilla status keywords are confusing.
Indeed they are. Those closing the bug should provide a justification
message suitable for everyone, though.


3b) There's no threading in the bugs
Valid, although not too important for the common bug.

3c) It is in ascending order by date
NOTABUG :)
Top-posting is bad. It would be crazy to read the bug reports backwards.
I don't oppose to an option to show them in reverse order, though.

I also like how we have our bugzilla configured with the comment box in
the bottom, ie. where the new comment will be added, and just below the
last comment.


[4] He provided no step 4, so I'm adding another problem for naive
reporting not listed there: all bugzilla communication is in English.


5a) Bugzilla is not used to discuss fixing the bug but for discussing
where it appears.

The first step is always determining what needs to be fixed and how to
reproduce it. The how to do it is usually straightforward and doesn't
require discussion, although it is sometimes there (moreover, that
newbie reporter wouldn't understand them anyway, I expect him to think
"you're the developers, just fix it").


5b) watching these threads usually provides me with very little
information about what is happening with the bug, who is dealing with
it, what the proposed ETA is, whether it will be deployed now or rolled
into the next MediaWiki release, so on and so forth

Who says that anyone would do it? :)
Consider it won't be done until, someone says "fixed here".
Alternatively, if a developer is asking many quesitons about it, he may
be considering to fix it.
Time of deployment is usually on next deployment, which should be very
easy with the planned new two-week deployments.
https://blog.wikimedia.org/2012/04/12/mediawiki-1-20wmf1-deployment/

It used to be harder, like needing you to know the revision number and
the branch point of next release.

5c) real conversation happens elsewhere...
What makes you think there's any conversation at all?
I don't think there's much discussion needed on most bugs.

You should just wait until there's a message like "it's done here" in
bugzilla. Then there might be later objections at gerrit, though, which
may drift the conversation to a different site.


What may be harder and needing extra skills would be to actually bug the
right person convincing them to implement a fix for that little bug that
really annoys you.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[phoebe ayers]

On Sun, May 13, 2012 at 9:26 AM, Platonides  wrote:
> On 12/05/12 18:17, David Gerard wrote:
>> Discussion on Oliver Keyes' blog:
>>
>>     http://quominus.org/archives/714
>>
>> He's coming from the perspective of liaison with newbies. Read the comments.
>
> I have to say it's the first time I met him.
>
> I'll try to summarise his points below with my comments:
>
> 1a) The steps are not clear.
>
> Solution: Make the "Enter a new bug report" link of
> https://bugzilla.wikimedia.org/ much bigger.
>
> The intermediate page asking you to login is not "cool", but I think
> that's a clear enough path.
>
>
> 1b) There's no indication that your login is your email.
>
> Granted. This can be confusing. Specially for the perspective of a
> mediawiki user.
> The only positive point might be that, if you have recently registered,
> you probably remember that your email is your login.
>
> The email sent by bugzilla does help, although it isn't explicit, either:
>> To use the wonders of Bugzilla, you can use the following:
>>
>>  E-mail address: platoni...@gmail.com
>>        Password: HPqd4NwIu
>
> Proposal: Add a message at the front page noting that you need a
> different login for bugzilla, that it is our email, and it'll be
> publicly visible.

+1. This is probably the biggest problem I have using bugzilla as an
occasional, non-technical user :)

If there's any way to tie the login to SUL that would be cool, but
just providing more explanatory messages would be helpful!

-- phoebe

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Helder Wiki]

On Sun, May 13, 2012 at 2:23 PM, phoebe ayers  wrote:
> If there's any way to tie the login to SUL that would be cool, but
> just providing more explanatory messages would be helpful!
This would be
https://bugzilla.wikimedia.org/show_bug.cgi?id=29853
which is a duplicate of
https://bugzilla.wikimedia.org/show_bug.cgi?id=27852

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Krinkle]

TL;DR: Reduce number of fields in our BugZilla. Simplify access to search 
filters.

See also https://www.mediawiki.org/wiki/Bugzilla which covers a fair bit for
newbies. Doesn't make BugZilla better, but it does offer a guide for new users.

Regarding target audience. I think it is fair to say that our Bugzilla is
primarily intended for developers (be it staff developers, volunteer
contributors developing core and/or extensions, or other interested tech-savvy
users who are an editor on a MediaWiki-powered site or maybe own their own
MediaWiki site). Not readers or editors of MediaWiki sites themselves,
directly.

MediaWiki sites (e.g. English Wikipedia, or your-wiki.example.org) have a local
place for feedback. For Wikimedia wikis, this local place for feedback would be
the village pump. Or maybe a generic feedback tool. Not BugZilla.

I don't think the issue tracker that developers use should be designed so that a
reader can figure out that a spelling mistake should be reported/fixed on
translatewiki, or that a bug in the watchlist should be reported on "MediaWiki
core > Watchlist", or that a feature request for whatever aborted his edit
should be filed under "MediaWiki extensions > AbuseFilter". Readers are best
leaving comments in a discussion forum. And users can help each other figure out
whether there is a way already or maybe the user did something wrong.

Anyone participating in a local discussion environment who feels technically
responsible for the site (site-admins) or are tech-savvy community members
(basically anyone who would know what a MediaWiki extension is and understand
Special:Version's content).. those detect "bugs" and "feature request" when they
appear in local fora and they report them upstream to the software bug tracker.

Don't get me wrong though, I agree completely that BugZilla feels like a
complete hack in the front end. Even for those that are the primary intended
audience (anyone who knows which product/component may be relevant and what a
bug report should contain), it is still an unusable nightmare in many aspects.
And even for those that aren't the primary intended users of the bug tracker, to
outside users it should still be easy to follow and understand the progress,
without necessarily knowing how or wanting to participate. And currently neither
is easy in BugZilla.

For the developer/Bugzilla side of issue tracking, one of the main problem with
Bugzilla infrastructure is in my opinion its complexity and over-organization of
meta data[1]. I think the only fields we need as key/value pairs are:
- Component
- Title
- Assignee
- Target Milestone
- Keywords
- Dependency tree

And of course general timeline items like attachments, comments, overal
open/close status and CC. And considering the large scope of our Bugzilla
install, the component category ("Product") may also be justified. And the
voting system can be used to prevent the useless +1 comments.

Assignee should be empty by default, only set when going to be worked on.
Current "Default assignee" should in most cases be default CC. Then we won't
need status "ASSIGNED" anymore (which is currently often forgotten, but due to
the "default assignee" stuff, one can often not see whether it's really on
someone's list).

I'm convinced all other fields can be done without and removing them will
improve the workflow of the developers and the Bugmeister. Including, but not
limited to:
- Platform (Hardware/OS)
- See also
- Web browser
- URL
These are rarely used and can just be put in the comments. Maybe URL is a nice
one to have aggregated to the top of the bug view. But even then it is limited
to a single url only (and has no label). Should still have a comment, so might
as well not have that field.
- Priority
- Severity
Use milestones and keywords instead ("MediaWiki 1.20.0 release",
"code-update-regression", ..) Those are more descriptive and easy to track and
understand. The only useful key-value of those is "severity: enhancement" to
distinguish between a bug and an improvement, but we can just use a keyword for
that.
- Close values (RESOLVED, FIXED, WORKSFORME, VERIFIED, DUPLICATE, ...)
Close reason and addendums (like "verified") can be put in comments. Plain
Open/Close is all we need.

Check out this presentation by Zach Holman (from GitHub) "How GitHub uses
GithHub to build GitHub". It is about how they work internally at GitHub (and a
bit about how GitHub helps them to do that, but it could be "How Wikimedia uses
[Code review, MediaWiki.org, Mailing lists, Bugzilla] to build MediaWiki" :D). 
* Video: http://zachholman.com/talk/how-github-uses-github-to-build-github
Specifically the section about Issues (slide 55 and on):
*
https://speakerdeck.com/u/holman/p/how-github-uses-github-to-build-github?slide=55

Note that the navigation portal[2] I recently created for BugZilla (mostly for
my own use, but you may find it useful too), encourages the above workflow. All
that matters there is the product, milestone and wheth

Re: [Wikitech-l] The bugtracker problem, again

[K. Peachey]

On Mon, May 14, 2012 at 12:55 PM, Krinkle  wrote:
> I'm convinced all other fields can be done without and removing them will
> improve the workflow of the developers and the Bugmeister. Including, but not
> limited to:
> - Platform (Hardware/OS)
> - See also
> - Web browser
> - URL
> These are rarely used and can just be put in the comments. Maybe URL is a nice
> one to have aggregated to the top of the bug view. But even then it is limited
> to a single url only (and has no label). Should still have a comment, so might

URL is nice and used more on the Site request type bugs, I also find
that it being limited to one url is =(, I know there is the See Also
field, but for some reasons the BZ devs have decided this should be
locked to support certain urls only (Unless they have changed their
view since the last time I went diving in the BZ BZ)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Krinkle]

On May 14, 2012, at 5:04 AM, K. Peachey wrote:

> On Mon, May 14, 2012 at 12:55 PM, Krinkle  wrote:
>> I'm convinced all other fields can be done without and removing them will
>> improve the workflow of the developers and the Bugmeister. Including, but not
>> limited to:
>> - Platform (Hardware/OS)
>> - See also
>> - Web browser
>> - URL
>> These are rarely used and can just be put in the comments. Maybe URL is a 
>> nice
>> one to have aggregated to the top of the bug view. But even then it is 
>> limited
>> to a single url only (and has no label). Should still have a comment, so 
>> might
> 
> URL is nice and used more on the Site request type bugs, I also find
> that it being limited to one url is =(, I know there is the See Also
> field, but for some reasons the BZ devs have decided this should be
> locked to support certain urls only (Unless they have changed their
> view since the last time I went diving in the BZ BZ)

Well, one doesn't need a URL field to link to the local discussion.
One can just put that in a comment. Which many do (even in Site requests).

-- Krinkle


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Gerard Meijssen]

Hoi,
MantisBT is localised at translatewiki.net. Given that we are talking about
software to be used by the Wikimedia Foundation, it is a VERY important
consideration. It beats hands down other software like MathJax that is
considered to be usable and is not ieven internationalised.
Thanks,
 GerardM

On 12 May 2012 18:17, David Gerard  wrote:

> Discussion on Oliver Keyes' blog:
>
>http://quominus.org/archives/714
>
> He's coming from the perspective of liaison with newbies. Read the
> comments.
>
> (I will note that Antoine Musso was right in the previous discussion
> that Mantis has a nice, friendly interface. I myself was most
> displeased to discover that (a) the code itself is really horrible (b)
> it's all but unsupported even to free-software standards.)
>
>
> - d.
>
> ___
> 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

Re: [Wikitech-l] The bugtracker problem, again

[Daniel Andre]

Disclaimer: I'm the lead developer of the bug genie (
http://www.thebuggenie.com), which was marked for consideration last time
this issue was discussed. This is also one of the main reasons I'm
following this thread.

I don't think you'll ever find a finished bug-/issue-tracking solution that
caters just as well for newbies and developers. The main reason is (of
course?) that most issue tracking software is written for developers, by
developers with little or no experience or thought as to what makes a good
end-user experience. Also, most issue tracking tools are *made
deliberately* to work best for developers - with human (end-user)
interaction kept to a minimum. That's also why most issue tracking
solutions end up looking like glorified (not the good kind) spreadsheets
(Mantis, Flyspray, others?), something the IRS would want you to fill out
(BZ, OTRS, RT, others?), or some kind of bastard child in-between (The Bug
Genie, Redmine, Jira, Fogbugz, others?).

Each of those approaches have their strengths, but unless you want to build
something like getsatisfaction.com - trying to be both completely
non-technical for non-technical users ("This issue makes me sad"), and at
the same time try to give power-users or developers good tools - then
you're gonna have to just figure out which issue tracking solution sucks
least, and then go with that. There's only so much styling can do to hide
the techie stuff from non-techie users, but you also don't want to hide all
the techie stuff away so your developers are dumbed down. It's a hard line
to find, and I think neither we, Mantis, BZ or any others really "do it
right". Some issue tracking systems will want to keep a strong focus on the
user experience for both non-techie users as well as developers, whereas
others really don't care that much. Licensing issues aside, it's a tricky
issue to find the right balance - in the end, you'll probably end up
figuring good old BZ does the trick - and if it's the solution that sucks
the least for you, then that's the one to go with.

All developers probably have their pet issue tracking system(s), and can go
on and on about the wonders of it. I could go on and on about why TBG is a
really good solution - but just saying "TBG is great, we (you) should all
use that" really doesn't show much insight.

I hope I can contribute something to the discussion - I certainly know what
TBG's strengths are, at least in relation to the WMF - where it would be a
good fit and where it would be a bad fit.


Regards,
Daniel André Eikeland


On Mon, May 14, 2012 at 8:45 AM, Gerard Meijssen
wrote:

> Hoi,
> MantisBT is localised at translatewiki.net. Given that we are talking
> about
> software to be used by the Wikimedia Foundation, it is a VERY important
> consideration. It beats hands down other software like MathJax that is
> considered to be usable and is not ieven internationalised.
> Thanks,
> GerardM
>
> On 12 May 2012 18:17, David Gerard  wrote:
>
> > Discussion on Oliver Keyes' blog:
> >
> >http://quominus.org/archives/714
> >
> > He's coming from the perspective of liaison with newbies. Read the
> > comments.
> >
> > (I will note that Antoine Musso was right in the previous discussion
> > that Mantis has a nice, friendly interface. I myself was most
> > displeased to discover that (a) the code itself is really horrible (b)
> > it's all but unsupported even to free-software standards.)
> >
> >
> > - d.
> >
> > ___
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Ryan Lane]

> I don't think you'll ever find a finished bug-/issue-tracking solution that
> caters just as well for newbies and developers. The main reason is (of
> course?) that most issue tracking software is written for developers, by
> developers with little or no experience or thought as to what makes a good
> end-user experience. Also, most issue tracking tools are *made
> deliberately* to work best for developers - with human (end-user)
> interaction kept to a minimum. That's also why most issue tracking
> solutions end up looking like glorified (not the good kind) spreadsheets
> (Mantis, Flyspray, others?), something the IRS would want you to fill out
> (BZ, OTRS, RT, others?), or some kind of bastard child in-between (The Bug
> Genie, Redmine, Jira, Fogbugz, others?).
>

I'd like to go one step further. There is not a single good bug/issue
tracking system in existence. Yes, I'm completely serious too. I've
come to believe that it's impossible to make one that anyone will be
happy with. That includes most developers of tracking systems too
(I've written one, and I hated it, though I liked it better than what
I was using before).

We can complain about this till the end of time. This discussion is
even worse than bikeshedding discussions. At least with bikeshedding
discussions you end up with a color for the bikeshed. When discussing
bug/issue trackers you just end up with the same tracker, or another
crappy tracker.

- Ryan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[David Gerard]

On 14 May 2012 09:10, Ryan Lane  wrote:

> I'd like to go one step further. There is not a single good bug/issue
> tracking system in existence. Yes, I'm completely serious too. I've
> come to believe that it's impossible to make one that anyone will be
> happy with. That includes most developers of tracking systems too
> (I've written one, and I hated it, though I liked it better than what
> I was using before).


It is true: all bug trackers suck ...


> We can complain about this till the end of time. This discussion is
> even worse than bikeshedding discussions. At least with bikeshedding
> discussions you end up with a color for the bikeshed. When discussing
> bug/issue trackers you just end up with the same tracker, or another
> crappy tracker.


... however, some suck even more than others.

Given this, it should be possible to point it in the direction of sucking less.

What do we need to do to improve Bugzilla to our ends? What are the
bugs in our Bugzilla installation? Can we agree on them? Is there
anyone to work on them?


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Platonides]

Much appreciated, Daniel.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Diederik van Liere]

I don't think we should aim to cater to non-developers at all. The changes that 
a non-developer finds a real bug are very very small (in my previous life as an 
academic I have done a lot of research on Bugzilla and developer productivity 
and it's based on that experience that I am making this statement). I think 
that if a newbie / non-developer finds bugzilla then he /she should be 
redirected to either IRC / Teahouse / Talk pages / FAQ or any other support 
channel that we have. They can always be send back to file a bug report. 

If we are going to spend effort on improving bugzilla then it should be focused 
(IMHO) on matching a bug with the right developer (right meaning a person who 
can actually fix the problem). It is this area that Bugzilla (or any other bug 
tracker AFAIK)  provides very limited support. 

-- Diederik
On 2012-05-14, at 1:10 AM, Ryan Lane wrote:

>> I don't think you'll ever find a finished bug-/issue-tracking solution that
>> caters just as well for newbies and developers. The main reason is (of
>> course?) that most issue tracking software is written for developers, by
>> developers with little or no experience or thought as to what makes a good
>> end-user experience. Also, most issue tracking tools are *made
>> deliberately* to work best for developers - with human (end-user)
>> interaction kept to a minimum. That's also why most issue tracking
>> solutions end up looking like glorified (not the good kind) spreadsheets
>> (Mantis, Flyspray, others?), something the IRS would want you to fill out
>> (BZ, OTRS, RT, others?), or some kind of bastard child in-between (The Bug
>> Genie, Redmine, Jira, Fogbugz, others?).
>> 
> 
> I'd like to go one step further. There is not a single good bug/issue
> tracking system in existence. Yes, I'm completely serious too. I've
> come to believe that it's impossible to make one that anyone will be
> happy with. That includes most developers of tracking systems too
> (I've written one, and I hated it, though I liked it better than what
> I was using before).
> 
> We can complain about this till the end of time. This discussion is
> even worse than bikeshedding discussions. At least with bikeshedding
> discussions you end up with a color for the bikeshed. When discussing
> bug/issue trackers you just end up with the same tracker, or another
> crappy tracker.
> 
> - Ryan
> 
> ___
> 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

Re: [Wikitech-l] The bugtracker problem, again

[Martijn Hoekstra]

Thats actually quite an interesting thought, and it could well be
true, even if it is the opposite of the Wiki philosophy.

On the other hand, it might also be true that non-developers do find
bugs, but fail to report them exactly because of the BZ user
experience. It's quite important that reporters don't 'get in the way'
of development. Keeping them out of the devolopers shouldn't be done
by erecting walls of artificial difficulties - which is what BZ'ed
user experience is, it hides the difficulty of finding and properly
reporting a bug in itself behind the difficulty of going through the
technical process of reporting a bug.

How it should be done is a more difficult question though. Hardly
anyone equipped to do proper triage from the firehose of a
low-boundries bugtracker is interested in actually doing that triage
(see also: code review)

On Mon, May 14, 2012 at 5:46 PM, Diederik van Liere  wrote:
> I don't think we should aim to cater to non-developers at all. The changes 
> that a non-developer finds a real bug are very very small (in my previous 
> life as an academic I have done a lot of research on Bugzilla and developer 
> productivity and it's based on that experience that I am making this 
> statement). I think that if a newbie / non-developer finds bugzilla then he 
> /she should be redirected to either IRC / Teahouse / Talk pages / FAQ or any 
> other support channel that we have. They can always be send back to file a 
> bug report.
>
> If we are going to spend effort on improving bugzilla then it should be 
> focused (IMHO) on matching a bug with the right developer (right meaning a 
> person who can actually fix the problem). It is this area that Bugzilla (or 
> any other bug tracker AFAIK)  provides very limited support.
>
> -- Diederik
> On 2012-05-14, at 1:10 AM, Ryan Lane wrote:
>
>>> I don't think you'll ever find a finished bug-/issue-tracking solution that
>>> caters just as well for newbies and developers. The main reason is (of
>>> course?) that most issue tracking software is written for developers, by
>>> developers with little or no experience or thought as to what makes a good
>>> end-user experience. Also, most issue tracking tools are *made
>>> deliberately* to work best for developers - with human (end-user)
>>> interaction kept to a minimum. That's also why most issue tracking
>>> solutions end up looking like glorified (not the good kind) spreadsheets
>>> (Mantis, Flyspray, others?), something the IRS would want you to fill out
>>> (BZ, OTRS, RT, others?), or some kind of bastard child in-between (The Bug
>>> Genie, Redmine, Jira, Fogbugz, others?).
>>>
>>
>> I'd like to go one step further. There is not a single good bug/issue
>> tracking system in existence. Yes, I'm completely serious too. I've
>> come to believe that it's impossible to make one that anyone will be
>> happy with. That includes most developers of tracking systems too
>> (I've written one, and I hated it, though I liked it better than what
>> I was using before).
>>
>> We can complain about this till the end of time. This discussion is
>> even worse than bikeshedding discussions. At least with bikeshedding
>> discussions you end up with a color for the bikeshed. When discussing
>> bug/issue trackers you just end up with the same tracker, or another
>> crappy tracker.
>>
>> - Ryan
>>
>> ___
>> 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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Risker]

Martijn is on to something here.  I write as a non-developer who has
identified bugs and has been pressed to report them via Bugzilla, despite
the fact that I feel very much out of my depth there.  For those of us who
can report problems but not solve them (other than to test solutions), a
simpler process would probably help to ensure that the bugs are reported in
a more standard way that is most likely to be useful to the developer team.

On a side note, Bugzilla is also used not just to report bugs but to
request enhancements and/or activation of extensions.  This can be the
developer equivalent of walking through a field of landmines, as many are
not familiar enough with the disparate communities to determine whether
this is actually a community request or just a bunch of guys on a
little-watched page asking for something.  The communities can get pretty
nasty with the developer team if an unexpected change is made, so finding a
better way to resolve these issues would be mutually beneficial.

Risker/Anne

On 14 May 2012 12:07, Martijn Hoekstra  wrote:

> Thats actually quite an interesting thought, and it could well be
> true, even if it is the opposite of the Wiki philosophy.
>
> On the other hand, it might also be true that non-developers do find
> bugs, but fail to report them exactly because of the BZ user
> experience. It's quite important that reporters don't 'get in the way'
> of development. Keeping them out of the devolopers shouldn't be done
> by erecting walls of artificial difficulties - which is what BZ'ed
> user experience is, it hides the difficulty of finding and properly
> reporting a bug in itself behind the difficulty of going through the
> technical process of reporting a bug.
>
> How it should be done is a more difficult question though. Hardly
> anyone equipped to do proper triage from the firehose of a
> low-boundries bugtracker is interested in actually doing that triage
> (see also: code review)
>
> On Mon, May 14, 2012 at 5:46 PM, Diederik van Liere 
> wrote:
> > I don't think we should aim to cater to non-developers at all. The
> changes that a non-developer finds a real bug are very very small (in my
> previous life as an academic I have done a lot of research on Bugzilla and
> developer productivity and it's based on that experience that I am making
> this statement). I think that if a newbie / non-developer finds bugzilla
> then he /she should be redirected to either IRC / Teahouse / Talk pages /
> FAQ or any other support channel that we have. They can always be send back
> to file a bug report.
> >
> > If we are going to spend effort on improving bugzilla then it should be
> focused (IMHO) on matching a bug with the right developer (right meaning a
> person who can actually fix the problem). It is this area that Bugzilla (or
> any other bug tracker AFAIK)  provides very limited support.
> >
> > -- Diederik
> > On 2012-05-14, at 1:10 AM, Ryan Lane wrote:
> >
> >>> I don't think you'll ever find a finished bug-/issue-tracking solution
> that
> >>> caters just as well for newbies and developers. The main reason is (of
> >>> course?) that most issue tracking software is written for developers,
> by
> >>> developers with little or no experience or thought as to what makes a
> good
> >>> end-user experience. Also, most issue tracking tools are *made
> >>> deliberately* to work best for developers - with human (end-user)
> >>> interaction kept to a minimum. That's also why most issue tracking
> >>> solutions end up looking like glorified (not the good kind)
> spreadsheets
> >>> (Mantis, Flyspray, others?), something the IRS would want you to fill
> out
> >>> (BZ, OTRS, RT, others?), or some kind of bastard child in-between (The
> Bug
> >>> Genie, Redmine, Jira, Fogbugz, others?).
> >>>
> >>
> >> I'd like to go one step further. There is not a single good bug/issue
> >> tracking system in existence. Yes, I'm completely serious too. I've
> >> come to believe that it's impossible to make one that anyone will be
> >> happy with. That includes most developers of tracking systems too
> >> (I've written one, and I hated it, though I liked it better than what
> >> I was using before).
> >>
> >> We can complain about this till the end of time. This discussion is
> >> even worse than bikeshedding discussions. At least with bikeshedding
> >> discussions you end up with a color for the bikeshed. When discussing
> >> bug/issue trackers you just end up with the same tracker, or another
> >> crappy tracker.
> >>
> >> - Ryan
> >>
> >> ___
> >> 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
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org

Re: [Wikitech-l] The bugtracker problem, again

[Steven Walling]

On Mon, May 14, 2012 at 9:19 AM, Risker  wrote:

> On a side note, Bugzilla is also used not just to report bugs but to
> request enhancements and/or activation of extensions.  This can be the
> developer equivalent of walking through a field of landmines, as many are
> not familiar enough with the disparate communities to determine whether
> this is actually a community request or just a bunch of guys on a
> little-watched page asking for something.  The communities can get pretty
> nasty with the developer team if an unexpected change is made, so finding a
> better way to resolve these issues would be mutually beneficial.
>

This is a lot more than a side issue. I think discussing enhancements,
permissions changes, and other things that aren't strictly bugs is the
worst thing about Bugzilla. These issues are often tendentious without
subjecting them to Bugzilla's very clunky commenting system that aggravates
the problem in so many ways.

The recent change to the watchlist and history functions on English
Wikipedia is a good example of this problem, as is the enormous discussion
on the bug requesting article creation permissions changes for EN-WP.

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l