Bug Importance

[David E. Ross]

I am seeing a number of bugzilla.mozilla.org bug reports submitted by
Mozilla developers with the Importance set at Normal.

The stated definition of "Normal" is a software error that involves
"some loss of functionality under specific circumstances" while these
bug reports clearly fail to identify any software error at all. Instead
these bug reports involve a "request for enhancement", which has the
Importance set at Enhancement.

Is no one monitoring this situation?

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[Boris Zbarsky]

On 4/4/12 1:41 PM, David E. Ross wrote:
> Is no one monitoring this situation?

Yep. I certainly pretty much ignore the Importance field, both when
filing and when prioritizing bugs, since it's usually noise, except when
explicitly set to blocker or critical. And even then it's often noise.

-Boris

[Kevin Brosnan]

On Wednesday, April 04, 2012 10:41:24, David E. Ross wrote:
> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> Mozilla developers with the Importance set at Normal.
>
> The stated definition of "Normal" is a software error that involves
> "some loss of functionality under specific circumstances" while these
> bug reports clearly fail to identify any software error at all. Instead
> these bug reports involve a "request for enhancement", which has the
> Importance set at Enhancement.
>
> Is no one monitoring this situation?
>

Different products have different rules for how they manage bugs. For
example the mobile group, anything in Fennec/Fennec Native, only uses
the priority field in Bugzilla for tracking how important a fix is.

Kevin

[L. David Baron]

On Wednesday 2012-04-04 10:41 -0700, David E. Ross wrote:
> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> Mozilla developers with the Importance set at Normal.
>
> The stated definition of "Normal" is a software error that involves
> "some loss of functionality under specific circumstances" while these
> bug reports clearly fail to identify any software error at all. Instead
> these bug reports involve a "request for enhancement", which has the
> Importance set at Enhancement.
>
> Is no one monitoring this situation?

I think the best solution would be to remove the Importance field
from bugzilla.mozilla.org. My impression is that the Importance
field is generally ignored, so suggesting to people that they should
spend time setting it correctly is wasting their time.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[Ben Bucksch]

On 04.04.2012 19:41, David E. Ross wrote:
> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> Mozilla developers with the Importance set at Normal.

> ...these bug reports involve a "request for enhancement"

>
> Is no one monitoring this situation?

I also closely monitor the fact that people file bugs with OS: Linux,
although the bug applies to all operating systems and CPUs. This is
directly discriminating those other OSes, and I object to that.

In addition, I also monitor people who post from "nowhere". This is an
unbearable situation.

[Boris Zbarsky]

On 4/4/12 2:06 PM, L. David Baron wrote:
> I think the best solution would be to remove the Importance field
> from bugzilla.mozilla.org.

Amen.

-Boris

[Jeff Hammel]

On 04/04/2012 11:07 AM, Ben Bucksch wrote:
> On 04.04.2012 19:41, David E. Ross wrote:
>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>> Mozilla developers with the Importance set at Normal.
>> ...these bug reports involve a "request for enhancement"
>>
>> Is no one monitoring this situation?
>
> I also closely monitor the fact that people file bugs with OS: Linux,
> although the bug applies to all operating systems and CPUs. This is
> directly discriminating those other OSes, and I object to that.

I also have a bit of an allergy to people that don't put in platform
correctly. I understand why the default is there -- to get as much info
as possible from people who may not be filling out a bug report
correctly, typically those new to bugzilla. But, especially (?) not
working on mozilla-central, I see many things that are blatantly
misfiled. This wouldn't matter so much if it weren't for another class
of bugs: bugs that *could* be for a particular platform, but that I
highly *suspect* are not. Then I'm forced to ask in the bug if the
platform was actually meant, and if it was I have sometimes been met
with a harsh reply. </rant>

[Joshua Cranmer]

On 4/4/2012 12:41 PM, David E. Ross wrote:
> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> Mozilla developers with the Importance set at Normal.
>
> The stated definition of "Normal" is a software error that involves
> "some loss of functionality under specific circumstances" while these
> bug reports clearly fail to identify any software error at all. Instead
> these bug reports involve a "request for enhancement", which has the
> Importance set at Enhancement.
>
> Is no one monitoring this situation?
>

The distinction between an RFE and a bug is extremely fuzzy (which one
would 'not supporting the latest version of some protocol' fall under?).
The main rationale for the Importance is to indicate how critical it is
to be fixed, but we already track priority of fixes via other means. If
a developer is being paid to work on something, it doesn't matter all
that much if a bug is an enhancement or normal. I only make a
distinction in queries sometimes to exclude UNCONFIRMED enhancements
from aggregate counts since these are largely feature proposals that
will probably never got fixed but no one wants to actually discuss if it
would be WONTFIX or not.

[David Bruant]

Le 04/04/2012 20:15, Jeff Hammel a écrit :
> On 04/04/2012 11:07 AM, Ben Bucksch wrote:

>> On 04.04.2012 19:41, David E. Ross wrote:
>>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>>> Mozilla developers with the Importance set at Normal.
>>> ...these bug reports involve a "request for enhancement"
>>>
>>> Is no one monitoring this situation?
>>
>> I also closely monitor the fact that people file bugs with OS: Linux,
>> although the bug applies to all operating systems and CPUs. This is
>> directly discriminating those other OSes, and I object to that.

> I also have a bit of an allergy to people that don't put in platform
> correctly. I understand why the default is there -- to get as much
> info as possible from people who may not be filling out a bug report
> correctly, typically those new to bugzilla. But, especially (?) not
> working on mozilla-central, I see many things that are blatantly
> misfiled. This wouldn't matter so much if it weren't for another
> class of bugs: bugs that *could* be for a particular platform, but
> that I highly *suspect* are not. Then I'm forced to ask in the bug if
> the platform was actually meant, and if it was I have sometimes been
> met with a harsh reply. </rant>

Could it be consider to set the platform field to "all" by default?
Or maybe the platform detected, but only for people who are new to Bugzilla?
I file bugs mostly on the JS engine or recently on devtools and these
issues are rarely related to one platform.

Also, some components (evangelism, documentation, marketing, websites,
etc.) don't need a platform at all.

I think it certainly made sense at the beginnings of Firefox to fill
this component, but I'm under the impression that platform-specific
issues have mostly been worked around and solutions for them are mature,
so fewer bugs are platform-specific now. Maybe it makes sense to default
to "all platform".

David

[Dave Mandelin]

+1. For user-sourced bugs, it can be useful to know the system of the reporters, but you can get that info just by asking. And if multiple users are giving info in the bug, you can *only* get the system of the other users by asking.

Cryptic aside: the way *all* key information (importance, affected platforms, etc.) is tracked in bugzilla feels hopelessly 20th-century-old-school-small-project to me.

[Dave Mandelin]

In JS, I completely ignore that field as noise.

It's kind of a problem because making sure the important bugs gets fixed does require tracking bug importance. A free-for-all importance field doesn't generate valid data, though, at least not with the current set of norms and practices.

I keep a text file on the side to track important bugs, but that's not a very good system either--I'd love to be able to share that info more easily.

[Dave Mandelin]

On Wednesday, April 4, 2012 11:15:19 AM UTC-7, Jeff Hammel wrote:

[Ben Bucksch]

On 04.04.2012 20:15, Jeff Hammel wrote:
> bugs that *could* be for a particular platform, but that I highly
> *suspect* are not. Then I'm forced to ask in the bug if the platform
> was actually meant, and if it was I have sometimes been met with a
> harsh reply.

In those cases, the "pp" (= platform parity) keyword should be added. I
also like the platform in the bug summary, e.g. "[Mac] Toolbar is too
high", as I think both add significant clarity.

(For the record, my post before was ironic.)

[Daniel Holbert]

On 04/04/2012 11:25 AM, David Bruant wrote:
> Could it be consider to set the platform field to "all" by default?

[...]

> I think it certainly made sense at the beginnings of Firefox to fill
> this component, but I'm under the impression that platform-specific
> issues have mostly been worked around and solutions for them are mature,

I still see bugs for platform-specific rendering issues. (whether
they're from graphics / printing / font differences / UA-sniffing)

I'd make two claims about the platform field:

(1) For a lot of bugs (e.g. "Implement New Feature X") it's not
important what the field's default value is -- it's not going to cause
confusion.

(2) For the bugs where the Platform field _might_ actually be relevant
(e.g. "Firefox prints/renders this page incorrectly"), then Bugzilla's
existing default (the bug-reporter's platform) is clearly the right
behavior. The bug could turn out to be cross-platform, but we shouldn't
assume that until it's been reproduced on another platform. (otherwise
someone might come along, misinterpret platform="All", and resolve the
bug as WORKSFORME since they can't reproduce it on their system)

On 04/04/2012 11:38 AM, Ben Bucksch wrote:
> (For the record, my post before was ironic.)

That's what I suspected. But now look what you've started! ;)

~Daniel

[Ben Bucksch]

On 04.04.2012 20:24, Dave Mandelin wrote:
> I keep a text file on the side to track important bugs, but that's not a very good system either--I'd love to be able to share that info more easily.

If you're a manager, the currently used hack is to use the whiteboard to
add [Dave:Cri] or similar. Of course, that doesn't scale.

[Alex Keybl]

That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on

Importance: P1-P5, {blocker, critical, major, normal, minor, trivial, enhancement}

and presumably continuing to rely upon tracking/status flags, feature pages, whiteboard entries, and offline methods for prioritization. Shouldn't we strive for greater transparency into the priorities of our engineering teams, both for the sake of our community as well as our project managers?

-Alex

On Apr 4, 2012, at 11:06 AM, L. David Baron wrote:

> On Wednesday 2012-04-04 10:41 -0700, David E. Ross wrote:

>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>> Mozilla developers with the Importance set at Normal.
>>
>> The stated definition of "Normal" is a software error that involves
>> "some loss of functionality under specific circumstances" while these
>> bug reports clearly fail to identify any software error at all. Instead
>> these bug reports involve a "request for enhancement", which has the
>> Importance set at Enhancement.
>>
>> Is no one monitoring this situation?
>

> I think the best solution would be to remove the Importance field

> from bugzilla.mozilla.org. My impression is that the Importance
> field is generally ignored, so suggesting to people that they should
> spend time setting it correctly is wasting their time.
>
> -David
>
> --
> 𝄞 L. David Baron http://dbaron.org/ 𝄂
> 𝄢 Mozilla http://www.mozilla.org/ 𝄂

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

[L. David Baron]

On Wednesday 2012-04-04 12:08 -0700, Alex Keybl wrote:
> That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on
>
> Importance: P1-P5, {blocker, critical, major, normal, minor, trivial, enhancement}

Sorry, I meant to say the "Severity" field is what we should remove.
I think developers usefully use Priority, and it also defaults to
unset, which is a reasonable default, rather than a randomly chosen
value, which confuses people.

(Alternatively, we could make Severity default to unset.)

[Benjamin Smedberg]

On 4/4/2012 3:08 PM, Alex Keybl wrote:

Note that the field we're talking about is the *Severity* field. The
Importance field is P1-P5. The severity field is blocker->enhancement.
The new bugzilla UI has hidden the label for the Severity so most people
assume that they are the same. Most people see the field and assume that
the Importance field actually means something about how important the
bug is to fix. But in many cases it is more valuable/important to fix a
minor issue that affects lots of people than to fix a crasher which
affects almost nobody. So *sorting* by the field isn't that important,
and querying by the field seems equally unhelpful in almost all cases.
So then it's just human-readable metadata, which we might as well just
put into nice human-readable forms like the whiteboard.

> That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on

You also have to understand the potential costs of actually keeping the
data in the field correct, and the bugmail costs of having people argue
about/keep changing the field (which happened a lot when I first started
with the project).

--BDS

[L. David Baron]

On Wednesday 2012-04-04 15:17 -0400, Benjamin Smedberg wrote:
> On 4/4/2012 3:08 PM, Alex Keybl wrote:
>
> Note that the field we're talking about is the *Severity* field. The
> Importance field is P1-P5. The severity field is

Actually, to be clear, the P1-P5 is the "Priority" field. That
shows up in the advanced query form.

> blocker->enhancement. The new bugzilla UI has hidden the label for
> the Severity so most people assume that they are the same. Most

The new bugzilla UI grouped the Priority and Severity fields into a
thing called "Importance". I believe the P1-P5 was previously
consistently labeled as Priority, and blocker-enhancement as
Severity.

[Alex Keybl]

> Note that the field we're talking about is the *Severity* field

Yep, I understand the differentiation you all are making now.

>> That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on
> You also have to understand the potential costs of actually keeping the data in the field correct, and the bugmail costs of having people argue about/keep changing the field (which happened a lot when I first started with the project).

Since we're now just talking about the severity, I don't have very strong feelings either way. If we had a more complete triage process in place, setting the severity would be a good first step (along with status/tracking flags) followed by setting the priority once assigned. Arguments could probably be avoided by only allowing the triagers and assignee to change the field.

-Alex

On Apr 4, 2012, at 12:17 PM, Benjamin Smedberg wrote:

> On 4/4/2012 3:08 PM, Alex Keybl wrote:
>

[Frédéric Buclin]

Le 04. 04. 12 20:06, L. David Baron a écrit :

> I think the best solution would be to remove the Importance field
> from bugzilla.mozilla.org.

I disagree. As Kevin said, different products (teams) have different
rules to track bugs. A critical bug is not the same as a minor bug, and
also not the same as a request for enhancement. This distinction remains
important. As a product manager, you can decide that such or such RFE is
very valuable and should really be implemented, without being a blocker
(i.e. "we should really have it, but we won't block the next release on
it"). In that case, this bug would have a severity of enhancement, but
with priority P1 or P2. Then some real bug could be somewhat major, but
not critical, and then only with priority P3. And another bug could be
pretty minor (e.g. a typo in a web page, but very visible because it's
in the title of an often visited page) and marked as P1 anyway. So both
fields are not directly related.

You may then say that looking at the priority of a bug is enough and is
the field which contains the relevant information, but the priority
field is only useful to paid people who are forced to fix bugs in the
order you prioritize them. Free contributors, such as me, are probably
more interested by the severity of a bug to decide which ones to fix
during their free time, independently of the priority set to it. For
instance, I'm the main triager for the Bugzilla team, and all bugs with
severity major or above are closely watched. This doesn't mean they are
top priority, but they are important bugs to fix and should remain in
our mind, and when a clever idea/solution comes to mind, we should
implement it or at least describe it in the bug asap. At this point, the
bug may get a higher priority because we know how to fix it in a clean
and clever way. As a consequence, we have no bugs with severity blocker
or critical, and only 5 bugs with severity major.

> My impression is that the Importance
> field is generally ignored, so suggesting to people that they should
> spend time setting it correctly is wasting their time.

Your approach is wrong: stop suggesting people to fix this field if your
team ignores it. This is also valid for the platform/OS fields. Stop
asking users to fix these fields if you ignore them. Also, don't include
them in your queries if you don't care about them. You are blaming
Bugzilla when you should blame the product managers. ;)


LpSolit

[Justin Wood (Callek)]

L. David Baron wrote:
> On Wednesday 2012-04-04 10:41 -0700, David E. Ross wrote:
>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>> Mozilla developers with the Importance set at Normal.
>>
>> The stated definition of "Normal" is a software error that involves
>> "some loss of functionality under specific circumstances" while these
>> bug reports clearly fail to identify any software error at all. Instead
>> these bug reports involve a "request for enhancement", which has the
>> Importance set at Enhancement.
>>
>> Is no one monitoring this situation?
>
> I think the best solution would be to remove the Importance field
> from bugzilla.mozilla.org. My impression is that the Importance
> field is generally ignored, so suggesting to people that they should
> spend time setting it correctly is wasting their time.
>

Outside of Core:: It is used (for some teams) quite heavily. e.g. IT
uses it to prioritize to a degree. such that depending on the importance
and the overall length a bug was open, etc. it might start paging people.

That is to say, if we can hide it for most of the project and only show
it where needed (or hide it and create a new field where
needed/makes-more-sense that could work as well)

--
~Justin Wood (Callek)

[Boris Zbarsky]

On 4/4/12 3:46 PM, Frédéric Buclin wrote:
> Your approach is wrong: stop suggesting people to fix this field if your
> team ignores it. This is also valid for the platform/OS fields. Stop
> asking users to fix these fields if you ignore them. Also, don't include
> them in your queries if you don't care about them. You are blaming
> Bugzilla when you should blame the product managers. ;)

You don't understand. It's users, especially bugzilla newbies, who keep
complaining that the fields are "set wrong". The product managers are
not the problem here.

The right solution is to hide the field in components where it's not
being used.

-Boris

[Gavin Sharp]

2012/4/4 Frédéric Buclin <LpS...@gmail.com>:

> I disagree. As Kevin said, different products (teams) have different
> rules to track bugs. A critical bug is not the same as a minor bug, and
> also not the same as a request for enhancement. This distinction remains
> important.

To you. Not to other users of b.m.o. We hit this wall every time
someone suggests making a change to b.m.o - there are many different
teams/projects sharing the one Bugzilla instance, and they all have
different habits, workflows, and norms. I think improving Bugzilla
would be a lot easier if proposed changes were implementable at the
Bugzilla "product" level, rather than site-wide. It shouldn't be
impossible to only hide certain fields for the
Core/Firefox/Toolkit/etc. products.

Gavin

[Steve Fink]

On 04/04/2012 11:25 AM, David Bruant wrote:

> Le 04/04/2012 20:15, Jeff Hammel a écrit :

>> On 04/04/2012 11:07 AM, Ben Bucksch wrote:

>>> On 04.04.2012 19:41, David E. Ross wrote:
>>>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>>>> Mozilla developers with the Importance set at Normal.
>>>> ...these bug reports involve a "request for enhancement"
>>>>
>>>> Is no one monitoring this situation?
>>> I also closely monitor the fact that people file bugs with OS: Linux,
>>> although the bug applies to all operating systems and CPUs. This is
>>> directly discriminating those other OSes, and I object to that.

>> I also have a bit of an allergy to people that don't put in platform
>> correctly. I understand why the default is there -- to get as much
>> info as possible from people who may not be filling out a bug report
>> correctly, typically those new to bugzilla. But, especially (?) not
>> working on mozilla-central, I see many things that are blatantly
>> misfiled. This wouldn't matter so much if it weren't for another

>> class of bugs: bugs that *could* be for a particular platform, but

>> that I highly *suspect* are not. Then I'm forced to ask in the bug if
>> the platform was actually meant, and if it was I have sometimes been

>> met with a harsh reply. </rant>

> Could it be consider to set the platform field to "all" by default?

> Or maybe the platform detected, but only for people who are new to Bugzilla?
> I file bugs mostly on the JS engine or recently on devtools and these
> issues are rarely related to one platform.

Platform means two totally different things, and neither is relevant
very often. (The two things are what platform was used to file the bug,
and what platform is believed to be affected by the bug.) It seems like
the best solution would be to split up those two meanings, and only set
the affected platform when explicitly deciding that it is relevant. So I
would propose: (1) have a custom field "reporter-platform" that is
automatically filled in when reporting a bug; (2) default the current
Architecture and Platform fields to 'unknown' or 'unset' (not 'all');
and (3) encourage people to only set the platform when it is believed to
be relevant. I'd prefer it if reporter-platform showed up in the inline
history display but nowhere else by default.

Then again, platform is so rarely relevant to me personally that fixing
any of this is low priority, so I'm just throwing out that proposal as
an idea for anyone who cares. I'd also note that "platform" is
unavoidably a rough approximation; sometimes the platform should be "any
POSIX system" or "system without hardware OpenGL acceleration" or
whatever. (In fact, this is the first I've noticed that architecture and
platform are separate, which is cool.)

I should note that I'm one of the jerks who regularly files a bug
observed on one system into bugzilla running on another system on a
different platform, and many bugs I file these days I do through a
script that doesn't bother with the platform at all. I will set the
platform when it is relevant, though, but there's no way to distinguish
those now.

>
> Also, some components (evangelism, documentation, marketing, websites,
> etc.) don't need a platform at all.
>

> I think it certainly made sense at the beginnings of Firefox to fill
> this component, but I'm under the impression that platform-specific
> issues have mostly been worked around and solutions for them are mature,

> so fewer bugs are platform-specific now. Maybe it makes sense to default
> to "all platform".
>
> David

[Steve Fink]

On a previous project where we actively made use of the priority field,
*only* the assignee would ever set priority. So really priority was only
meaningful within the subset of bugs assigned to a given developer. If
you took over somebody's bug, you'd set the priority according to your
personal prioritization (or reset it to the default if you didn't want
to think about it yet.) In that way, the priority field could be used
both as a personal TODO list as well as a communication mechanism for
people who wondered when a given bug was likely to be fixed. Managers
and users would never set the field. Well, ok, they would, but then it'd
be wrong and either reset or ignored. If they felt a bug was important
to be fixed, they'd set 'severity' accordingly.

I sort of assumed that was the standard bugzilla policy.

It seems like a workable system, and far better than attempting to do
product management via bugzilla priority fields. That generally seems to
produce way too much bug churn, and our product managers liked juggling
spreadsheets far better anyway.

[Scott Johnson]

On Wed 04 Apr 2012 01:17:44 PM PDT, Steve Fink wrote:
> On a previous project where we actively made use of the priority field,
> *only* the assignee would ever set priority. So really priority was only
> meaningful within the subset of bugs assigned to a given developer. If
> you took over somebody's bug, you'd set the priority according to your
> personal prioritization (or reset it to the default if you didn't want
> to think about it yet.) In that way, the priority field could be used
> both as a personal TODO list as well as a communication mechanism for
> people who wondered when a given bug was likely to be fixed. Managers
> and users would never set the field. Well, ok, they would, but then it'd
> be wrong and either reset or ignored. If they felt a bug was important
> to be fixed, they'd set 'severity' accordingly.

This is how I've been using the priority field, too. Should I stop
doing this? What method is used to prioritize bugs within a developer's
task list? I would hope the spreadsheet approach isn't the most widely
used...

> On 04/04/2012 12:46 PM, Frédéric Buclin wrote:

[Mike Hommey]

Or default to an empty value. If it is set, then you know it is meant to
be useful (or an expression of the annoying behaviour of bugzilla with
session restore).

Mike

[David E. Ross]

Which components are those?

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[Gavin Sharp]

On Wed, Apr 4, 2012 at 2:32 PM, David E. Ross <nob...@nowhere.invalid> wrote:
>> The right solution is to hide the field in components where it's not
>> being used.
>>
>> -Boris
>
> Which components are those?

All of the "Core" Mozilla product components - Core, Firefox,
Thunderbird, Toolkit, etc.

Gavin

[David E. Ross]

So even end-users such as I am can submit RFE bug reports for new or
changed features and mark them Normal instead of Enhancement?

[Gavin Sharp]

On Wed, Apr 4, 2012 at 4:34 PM, David E. Ross <nob...@nowhere.invalid> wrote:
> So even end-users such as I am can submit RFE bug reports for new or
> changed features and mark them Normal instead of Enhancement?

You (or anyone else) can mark them however you'd like - that field
just doesn't change anyone's behavior in any significant way, so its
value is ignored in practice.

Gavin

[Dave Mandelin]

I wanted to avoid cluttering bugs with more weird notations, but I may end up having to do that in order to keep things straight.

[Dave Mandelin]

"Shouldn't we strive for greater transparency into the priorities of our engineering teams, both for the sake of our community as well as our project managers?"

+1. I have started trying to comment more in bugs about what we're planning, but that doesn't scale to all the bugs.

[Dave Mandelin]

"Shouldn't we strive for greater transparency into the priorities of our engineering teams, both for the sake of our community as well as our project managers?"

+1. I have started trying to comment more in bugs about what we're planning, but that doesn't scale to all the bugs.

On Wednesday, April 4, 2012 12:08:48 PM UTC-7, Alex Keybl wrote:

[Alexander Surkov]

I track bugs having major importance in accessibility module. This
flag is used for bugs crucial for ATs. So in general I need two
importance values: normal and major. If crashes would be mapped to
major importance then it's still ok, excepting top crashers perhaps
(but I don't use importance field for those). But anyway I definitely
miss importance field if you get rid it at all.

Thanks.
Alex.

[Dave Townsend]

On 04/04/12 17:40, Dave Mandelin wrote:
> "Shouldn't we strive for greater transparency into the priorities of our engineering teams, both for the sake of our community as well as our project managers?"
>
> +1. I have started trying to comment more in bugs about what we're planning, but that doesn't scale to all the bugs.

In the Add-on SDK product we keep things pretty simple. We ignore the
severity field but use the priority field P1-P3 to mean need/want/nice
to have. The problem of course is that even though we weekly triage new
bugs to assign these, those values often get outdated.

[Byron Jones]

Gavin Sharp wrote:

> On Wed, Apr 4, 2012 at 2:32 PM, David E. Ross<nob...@nowhere.invalid> wrote:
>>> The right solution is to hide the field in components where it's not
>>> being used.

>> Which components are those?
> All of the "Core" Mozilla product components - Core, Firefox,
> Thunderbird, Toolkit, etc.

hiding the fields on a per-product basis would be an easy change to both
the non-guided enter_bug and show_bug forms.
i've filed bug 742634 to track this.

hiding the field on a per-component basis is non-trivial and probably
won't happen.

David Bruant wrote:
> Could it be consider to set the platform field to "all" by default?
> Or maybe the platform detected, but only for people who are new to Bugzilla?

i feel the crux of the problem is the dual usage of the platform field;
it's used to track both "the reporter's platform" and "this bug applies
to this platform".

note users who are new to bugzilla get a completely different bug entry
form/experience from what you're probably seeing (try switching to the
bugzilla helper from the enter_bug page). the guided bug entry form
(aka bugzilla helper) always prepends the reporter's user-agent to
comment 0, and performs platform/os detection on a limited subset of
products (firefox, fennec, seamonkey, camino, core, and thunderbird).
on all other products the platform/os is set to "all". firefox bugs are
forced into an "untriaged bugs" component, which enables some triage
love so there's a reasonable chance the platform/os fields will have
saner values by after triage.

non-guided bug management is yet to be updated.

possible changes for non-guided bug entry is to always prepend the
reporter's user agent to comment 0, and default the platform to "all"
for all products.
or add a read-only field (shudder, more fields) which captures the
reporter's user agent, and default the platform to "all".
or assume that if someone isn't using the guided form, they know what
they are doing, and default platform/os to "all" without capturing the
reporter's platform information.


--
byron - irc:glob - bugzilla.mozilla.org team -

[Justin Dolske]

On 4/4/12 12:51 PM, Boris Zbarsky wrote:

Yes. Though there are two problems intertwined here:

The immediate issue is that we have many components (effectively most of
the things that ship in Firefox) where these fields are meaningless and
unused. We should hide them, and eliminate an obvious point of confusion.

The more idealistic issue is finding the right degree of homogeneity
across bugzilla. It would suck for users to have to deal with or
understand multiple systems for how bugs are managed; but OTOH it also
seems a bit unfair to require everyone to conform to one system. Not
sure what the answer is here. It feels a bit like dueling goals... We
have enough diversity in BMO products/components that multiple ways of
managing could make sense, but at the same time the bigger Mozilla gets
the more useful it is to have consistency across areas. Perhaps the
answer lies in a clear difference between fields of relevance to
end-users vs those who drive a component. The blocking/tracking/approval
flags are, loosely, and example of this.

Justin

[Mark Banner]

Err wrong. Thunderbird, MailNews Core use at least the enhancement and
normal levels of Importance (we also use critical for crashes, but that
tends to be duplicated by the "crash" keyword.

Minor/Major and Blocking do get used, but not that extensively IMO.

Off the top of my head, I'd say we could probably remove that severity
field and replace it by one checkbox: enhancement.

Although I realise not everyone uses the enhancement field, we do get
lots of requests for enhancement, and I'd rather keep that distinction.

The other options would be either obsolete or indicated by keywords.

Mark.

[Mounir Lamouri]

On 04/04/2012 10:06 PM, Steve Fink wrote:
> Platform means two totally different things, and neither is relevant
> very often. (The two things are what platform was used to file the bug,
> and what platform is believed to be affected by the bug.) It seems like
> the best solution would be to split up those two meanings, and only set
> the affected platform when explicitly deciding that it is relevant. So I
> would propose: (1) have a custom field "reporter-platform" that is
> automatically filled in when reporting a bug; (2) default the current
> Architecture and Platform fields to 'unknown' or 'unset' (not 'all');
> and (3) encourage people to only set the platform when it is believed to
> be relevant. I'd prefer it if reporter-platform showed up in the inline
> history display but nowhere else by default.

IIRC, when you do not have certain bits enabled on your account, you
have to go trough a special form to file a bug and this form will
automatically add the UA used to file the bug. This is this same UA that
is used by bugzilla to set the 'Platform' fields so the information is
redundant in that case.
If you have the specific bit enabled, that means you know how to file a
bug and you will very likely add that information if it seems relevant.
In addition, setting the platform using the current UA means nothing
because I might see a bug on a system and file it with another. For
example, I do not file bugs with my phone.

Given that, IMO, we should always set the 'Platform' field to ALL/ALL by
default.

--
Mounir

[Philip Chee]

On Thu, 05 Apr 2012 11:12:56 +0200, Mounir Lamouri wrote:

> Given that, IMO, we should always set the 'Platform' field to ALL/ALL by
> default.

At the risk of bike-shedding, may I suggest instead
UNSPECIFIED/UNSPECIFIED (or Undefined or TBD)?

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[beltzner]

On Thu, Apr 5, 2012 at 2:57 AM, Justin Dolske <dol...@mozilla.com> wrote:
> is to have consistency across areas. Perhaps the answer lies in a clear
> difference between fields of relevance to end-users vs those who drive a
> component.

This, so very much this.

There are many ways one could choose to modify the design of Bugzilla
(and yes, I guess it is that time of year again!) in order to help
with this and other difficult interactions regarding the proper
filing, marking and tracking of bugs, but the one I seldom hear
offered is to provide different views based on the task / goals of the
user.

cheers,
mike

[Benjamin Smedberg]

On 4/5/2012 5:03 AM, Mark Banner wrote:
>
> Err wrong. Thunderbird, MailNews Core use at least the enhancement and
> normal levels of Importance (we also use critical for crashes, but
> that tends to be duplicated by the "crash" keyword.
>
> Minor/Major and Blocking do get used, but not that extensively IMO.
>
> Off the top of my head, I'd say we could probably remove that severity
> field and replace it by one checkbox: enhancement.

How do you currently use the field? For searches? I'd argue that
explicit metadata fields (either the severity dropdown or a separate
checkbox) are only useful if we need to search or order on the results.

I know that the server ops people use severity in this way quite
explicitly (to trigger oncall emails or pages, etc). But in the code
products, even in cases where the severity field is "correct", I've
never seen an automated query use the data in an especially useful way.
So if we could just mark enhancements in the bug comments or the
whiteboard, we'd achieve the same results for human readers without
having required metadata.

Presumably an enhancement keyword would be equivalent to an enhancement
checkbox?

--BDS

[Steve Wendt]

On 4/4/2012 11:24 PM, Byron Jones wrote:

> or assume that if someone isn't using the guided form, they know what
> they are doing, and default platform/os to "all" without capturing the
> reporter's platform information.

This sounds perfect, and is dead simple.

[Mike Hoye]

On 12-04-05 10:48 AM, beltzner wrote:

> There are many ways one could choose to modify the design of Bugzilla
> (and yes, I guess it is that time of year again!) in order to help
> with this and other difficult interactions regarding the proper
> filing, marking and tracking of bugs, but the one I seldom hear
> offered is to provide different views based on the task / goals of the
> user.

Following this thread and having some conversations around MoTo, the
following things are true:

- Probably no two people, and definitely no two teams, use Bugzilla's
flags the same way.

- Many people use Bugzilla fields that their team doesn't use for their
own reasons, which may conflict with other team members' uses. This
seems to be navigated based on ownership, with people not modifying
those flags in other people's bugs.

- Some of the ways some of the people use some of the flags aren't
cleanly aligned with with those flags' names or their historical usage
norms.


None of that would be a problem if it wasn't for the fact that
Bugzilla's data layer and presentation layer are inseparable. No one
team can have a view of their bugs that doesn't expose stuff they or
their team either don't care about, or that doesn't make sense or
doesn't agree with their team or personal norms.

Bugzilla doesn't need a big-bang redesign beyond a few sane-default
choices, but it does need to be _made designable_ by separating
presentation and data in a way that individuals and teams can modify to
their needs.

It doesn't have to be more complicated than an extension, I think, but
it does need two thing. The most important, I think, to admit that
Mozilla is now too big for there to be a de-jure, much less de-facto
internal monoculture, or One Right Way To Work.

The second is a way to publish those customizations, so that on a wiki
somewhere the (say) Accessibility or Graphics teams (or whoever) have a
say of saying, these are the parts of Bugzilla we focus on, so if you
want to bring something to our attention, these are the flags we
actually watch. this is the Bugzilla Dialect that we prefer.

A nice upside to this would be sane presentation-layer defaults for new
users, to smooth the new-contributor onramp by hiding the scarier and
noisier parts of bugzilla until they're ready to pull that curtain back
themselves.

--
Michael Hoye
Bespoke I/O
http://bespokeio.com

[Justin Lebar]

> [We should] admit that Mozilla is

> now too big for there to be a de-jure, much less de-facto internal
> monoculture, or One Right Way To Work.

While I agree with this, I disagree with the specific suggestions here.

In particular, I think it would be Bad if I had to install an
extension (or otherwise take some action locally) in order to see the
blessed "gfx/accessibility/whatever-centric" view of Bugzilla. Things
are already complex enough as-is, and this just adds a whole new set
of ways for me to screw things up.

What we've done in MemShrink is simply add [MemShrink:P{1,2,3}] to
bugs' whiteboards. This has worked out well for us. It's clear who
owns the priority, and it gives people a clear way to ask us to look
at a bug (just tag it with [MemShrink]).

[Mike Hoye]

On 12-04-05 3:17 PM, Justin Lebar wrote:
> While I agree with this, I disagree with the specific suggestions here.
>
> In particular, I think it would be Bad if I had to install an
> extension (or otherwise take some action locally) in order to see the
> blessed "gfx/accessibility/whatever-centric" view of Bugzilla. Things
> are already complex enough as-is, and this just adds a whole new set
> of ways for me to screw things up.

So, I expressed myself badly there: as you rightly note, that would
everyone has a worse problem.

What I meant by that was that it be put up as a way for teams to
communicate how they use bugzilla, and what's important to them in
Bugzilla's data fields. That is, a way to better understand each other
other teams, instead of another hurdle you have to overcome to get
anything done across teams.

[Zack Weinberg]

On 2012-04-04 11:15 AM, Jeff Hammel wrote:
> On 04/04/2012 11:07 AM, Ben Bucksch wrote:

>> On 04.04.2012 19:41, David E. Ross wrote:
>>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>>> Mozilla developers with the Importance set at Normal.

>>> ...these bug reports involve a "request for enhancement"

>>>
>>> Is no one monitoring this situation?
>>

>> I also closely monitor the fact that people file bugs with OS: Linux,
>> although the bug applies to all operating systems and CPUs. This is
>> directly discriminating those other OSes, and I object to that.

Discrimination against OSes where we are in direct competition with the
OS vendor is necessary for our long-term survival (hhos).

> I also have a bit of an allergy to people that don't put in platform
> correctly. I understand why the default is there -- to get as much info
> as possible from people who may not be filling out a bug report
> correctly, typically those new to bugzilla. But, especially (?) not
> working on mozilla-central, I see many things that are blatantly
> misfiled.

Nearly all the bugs I file, I know _a priori_ it's not a
platform-specific bug. Nearly all the platform-specific bugs I file are
reported to me by various informants, who are not using the same
platform as me. (And I can't remember the last time I filed a bug that
was in any way *CPU* specific, although I'm sure it happens,
particularly over in JIT land.) Therefore the default-from-user-agent
behavior is almost always wrong for me, and I know I don't always
remember to reset it.

Which is to say, I'd definitely support the defaults being changed to
all:all.

zw

[Robert Kaiser]

Benjamin Smedberg schrieb:

> But in the code
> products, even in cases where the severity field is "correct", I've
> never seen an automated query use the data in an especially useful way.

In earlier years of the SeaMonkey projects, we had regular bug triage on
"all old bugs that are not marked as enhancement", as real bugs were
often eliminated with switching to a different codebase or through other
work - RFEs mostly stayed valid.
Not sure if current drivers of the project are still doing this, though.

Robert Kaiser

[Daniel Veditz]

On 4/4/12 11:24 AM, Dave Mandelin wrote:
> I keep a text file on the side to track important bugs, but
> that's not a very good system either--I'd love to be able to
> share that info more easily.

Two bugzilla alternatives you can consider: tracking bugs and
tags/shared queries.

If you have a project goal that you think several team members will
be interested in you could have "tracking bug" with all of your
"important bugs" added to the "depends on" field.
- gets unwieldy for ongoing concepts like "important",
but works for "important for release X".
- if they're only important to -you- it clutters communal
bugzilla with personal bugs
- easily managed and shared with a team
- the tracking bug can be given an easily remembered "alias"

If this is a list of mostly personal interest then consider the
Bugzilla "tag" feature. You first have to turn it on in preferences,
and then you can easily add the current bug to any tagged list. The
tag will create a named query which is added to your page footer for
easy access.
- tagged list can be shared with others from the Saved Searches
tab in bugzilla prefs.
- somewhat clunky to manage, but not too different than
editing the "Depends on" field.

Neither is perfect, but might be better than "a text file on the side".

-Dan Veditz

[Dave Mandelin]

I thought of the tracking bug thing before, but for reasons I don't recall decided not to use it. Maybe it's because I reclassify bugs fairly often and also change the classification scheme, so there would be a lot of churn.

I'll look into the tags, though, next time I take a look at my systems. It might work well.

[Dave Mandelin]

On Friday, April 6, 2012 1:40:41 PM UTC-7, Daniel Veditz wrote:

[Byron Jones]

Mike Hoye wrote:
> None of that would be a problem if it wasn't for the fact that
> Bugzilla's data layer and presentation layer are inseparable. No one
> team can have a view of their bugs that doesn't expose stuff they or
> their team either don't care about, or that doesn't make sense or
> doesn't agree with their team or personal norms.

this is definitely not the case - bugzilla's data and presentation
layers are separate (internally and externally).

we have webservices which teams can, and do, use to provide their own
view of the data on bmo.

bugzilla has xml-rpc and json-rpc natively
(http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html),
and gerv has a proxy which sits in front of bmo which provides a REST
api (https://wiki.mozilla.org/Bugzilla:REST_API).

i'm also not against providing limited per-product customisation of the
native bugzilla UI on bmo.

[Gervase Markham]

On 05/04/12 19:35, Mike Hoye wrote:
> None of that would be a problem if it wasn't for the fact that
> Bugzilla's data layer and presentation layer are inseparable. No one
> team can have a view of their bugs that doesn't expose stuff they or
> their team either don't care about, or that doesn't make sense or
> doesn't agree with their team or personal norms.
>
> Bugzilla doesn't need a big-bang redesign beyond a few sane-default
> choices, but it does need to be _made designable_ by separating
> presentation and data in a way that individuals and teams can modify to
> their needs.

I don't think it's necessarily true to say that the data and
presentation layers are inseperable. There are 2 things which make this
not the case:

1) Template formats. Pretty much any Bugzilla screen can have multiple
HTML views; all that's required is writing a template in Template
Toolkit. Usually, this feature is used to e.g. provide CSV forms of
buglists, but there's no reason that a page can't have two HTML
versions. The enter bug page does:

https://bugzilla.mozilla.org/enter_bug.cgi?format=guided
https://bugzilla.mozilla.org/enter_bug.cgi

If people want to write new templates for Bugzilla, get in touch and we
can show you how.

2) BzAPI. Write your own front end, exposing whatever data you like and
using web technologies, using Bugzilla's REST API:
https://wiki.mozilla.org/Bugzilla:REST_API

Gerv

[Mike Hoye]

On 12-04-09 7:32 AM, Byron Jones wrote:
>
> we have webservices which teams can, and do, use to provide their own
> view of the data on bmo.
>
> bugzilla has xml-rpc and json-rpc natively
> (http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html),
> and gerv has a proxy which sits in front of bmo which provides a REST
> api (https://wiki.mozilla.org/Bugzilla:REST_API).
>
> i'm also not against providing limited per-product customisation of the
> native bugzilla UI on bmo.

I've received this via email from a few other people as well. I've read
it a few times now, and I'm trying to figure out if there's a more
charitable way to interpret it than "If you don't like the bugzilla
interface, write your own. Patches accepted maybe, but probably not."

Right now, I'm looking at https://github.com/mozilla and I see that:

- BrowserID
- Mozillians
- OpenBadges
- OpenWebApps

are all doing their issue tracking over there. So are BrowserQuest and
PDF.js and DXR and a bunch of other projects that are important parts of
Mozilla's development processes or ecosystem or actual shipping products.

Those are just the ones I recognized well enough to drill into; that
list is pretty long.

Why are they all over there? I mean, git, sure. Git's awesome. But why
is all the issue tracking stuff over there too?

Is it because there's no formal policy about where Mozilla's bugs go, or
because the time-cost of using Bugzilla is comparatively too high for
people already at Github? Is it because the advantages of Git over the
current build process make balkanizing your knowledge base look like
acceptable collateral damage?

Maybe all those costs are hidden, or nobody's asked them not to do that.
Is it because it's just that much easier?

I don't have answers to those questions, but I sure hope they're on
somebody's radar, because you've got a real, systemic issue here that is
right-now-today actively fragmenting Mozilla's most important repository
of self-knowledge. And that's happening at the same time that the
organization is growing like mad.

This is large, structural problem with long-term implications. It's got
a UX component, sure, but it's also got a policy component and a
management component, and has as much to do with Mozilla's ability to
ship software a decade from now as it does with nagging day-to-day
usability problems.

How many new accounts on new services will somebody need to sign up for
in a decade, just to figure out where the bug they want to help with
actually lives? I can answer that, and it will be one of "zero", "one"
or "something is horribly wrong".

Gerv's API is great. XML-RPC and JSON-RPC: killer. Critical tools for
addressing these issues, no question. But this is a sprawling problem,
and as much as I wish otherwise, it's not something I think I can
address by reskinning Bugzilla just for me.

Thanks for your time,

[Joshua Cranmer]

On 4/10/2012 12:44 PM, Mike Hoye wrote:
> On 12-04-09 7:32 AM, Byron Jones wrote:
>>
>> we have webservices which teams can, and do, use to provide their own
>> view of the data on bmo.
>>
>> bugzilla has xml-rpc and json-rpc natively
>> (http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html),
>> and gerv has a proxy which sits in front of bmo which provides a REST
>> api (https://wiki.mozilla.org/Bugzilla:REST_API).
>>
>> i'm also not against providing limited per-product customisation of the
>> native bugzilla UI on bmo.
>
> I've received this via email from a few other people as well. I've
> read it a few times now, and I'm trying to figure out if there's a
> more charitable way to interpret it than "If you don't like the
> bugzilla interface, write your own. Patches accepted maybe, but
> probably not."
>
> Right now, I'm looking at https://github.com/mozilla and I see that:
>
> - BrowserID
> - Mozillians
> - OpenBadges
> - OpenWebApps
>
> are all doing their issue tracking over there. So are BrowserQuest and
> PDF.js and DXR and a bunch of other projects that are important parts
> of Mozilla's development processes or ecosystem or actual shipping
> products.
>

At least one of the projects you mentioned does not use github's issue
tracking (DXR uses Bugzilla more than github). I also see issue tracking
for some PDF.js stuff in Bugzilla.

Having used both Bugzilla and github's tracker, I can honestly say that
I prefer Bugzilla by several orders of magnitude. About the only benefit
that github has over Bugzilla is the tight integration with the VCS.

> I don't have answers to those questions, but I sure hope they're on
> somebody's radar, because you've got a real, systemic issue here that
> is right-now-today actively fragmenting Mozilla's most important
> repository of self-knowledge. And that's happening at the same time
> that the organization is growing like mad.

Is Bugzilla really more important a repository of self-knowledge then
any of our other repositories? Like mailing lists, newsgroups [1],
blogs, IRC, the wiki, devmo, mozillazine, and Firefox Input?

[1] Actually, the last time I checked, we had two separate mailing list
servers, some of which are further replicated on Google Groups and
another set are replicated on newsgroups. We may even have some Google
Groups things that aren't replicated on our own mailing list servers,
IIRC. How is this any less infuriating a fragmentation than having some
projects use bug trackers? Actually, many people file bugs in extensions
in bugzilla.mozilla.org instead of with the extension author. We also
have issues where bugs get reported for Firefox in other trackers (think
Ubuntu's or Debian's trackers, e.g.). It's not an insurmountable
problem, as long as there is someone who can redispatch bug reports to
appropriate places.

[Mike Hoye]

On 12-04-10 2:20 PM, Joshua Cranmer wrote:
> Actually, the last time I checked, we had two separate mailing list
> servers, some of which are further replicated on Google Groups and
> another set are replicated on newsgroups. We may even have some Google
> Groups things that aren't replicated on our own mailing list servers,
> IIRC. How is this any less infuriating a fragmentation than having some
> projects use bug trackers?

I think that where issues are discussed isn't as important as tracking
the progress of issues being resolved. But sure, it's not the only issue
Mozilla is facing. If you only had one, you wouldn't need an issue
tracker at all.

[Philip Chee]

Which brings up a point that wasn't adequately addressed the last time
this (github et al) was brought up. What backup contingency plans do we
have if GitHub goes tits-up? Originally it was suggested that Mozilla
hold a regularly upated git copy of all the Github Mozilla projects
behind our firewall. Has this been implemented?

The Github issue tracker might not so critical but useful technical
details might get lost in the shuffle. I believe that several Linux
distributors (e.g. Ubuntu) have some functionality that automatically
copies comments in b.m.o to their own bugzilla/issue tracker for Mozilla
bugs that they have dependencies for. Can we do the same here?

[Gervase Markham]

On 10/04/12 18:44, Mike Hoye wrote:
> I've received this via email from a few other people as well. I've read
> it a few times now, and I'm trying to figure out if there's a more
> charitable way to interpret it than "If you don't like the bugzilla
> interface, write your own.

That's basically what it is. Several people have. :-) We can't make the
UI all things to all people - that's why I wrote BzAPI. That doesn't
mean it can't be improved, but it does mean that the quickest route to
happiness for any one particular group may be to write their own tool.

> Patches accepted maybe, but probably not."

If it's just an alternative template view for a bug, I don't see any
reason the patch wouldn't be accepted.

> Why are they all over there? I mean, git, sure. Git's awesome. But why
> is all the issue tracking stuff over there too?

Integration, I suspect. Path of least resistance.

> Is it because there's no formal policy about where Mozilla's bugs go, or

I think it's more that there was an sort of assumed and therefore
unwritten policy about where Mozilla code goes, but it was unwritten and
therefore as we expanded, didn't get followed. And the bugs have
followed the code.

> I don't have answers to those questions, but I sure hope they're on
> somebody's radar, because you've got a real, systemic issue here that is
> right-now-today actively fragmenting Mozilla's most important repository
> of self-knowledge. And that's happening at the same time that the
> organization is growing like mad.

It's sort of on the radar. But what's the fix? The "don't use github"
horse has left the stable, left the village, and recently crossed the
state line still going at a furious clip. Moving everything to github
would be an enormous project and we'd be taking on some big risks. So
what do we do?

Gerv

[Robert Kaiser]

Mike Hoye schrieb:

> Why are they all over there? I mean, git, sure. Git's awesome. But why
> is all the issue tracking stuff over there too?

That's something that bothers me as well (along with all the review
comments and stuff being only there and not in Bugzilla, btw - for even
more than the projects you listed), esp. given that 1) GitHub is outside
of our control and can in theory be shut down due to forces we can't
control, taking all that info down with it and 2) AFAIK GitHub is a
proprietary, commercial toolset and entity, and I don't think it's good
in terms of the Mozilla mission and Manifesto to depend on such a
service this way and host vital project management (issue tracking) and
history there.

Robert Kaiser

[Mike Hoye]

On 12-04-11 10:42 AM, Gervase Markham wrote:
> On 10/04/12 18:44, Mike Hoye wrote:
>> Is it because there's no formal policy about where Mozilla's bugs go, or
>
> I think it's more that there was an sort of assumed and therefore
> unwritten policy about where Mozilla code goes, but it was unwritten and
> therefore as we expanded, didn't get followed. And the bugs have
> followed the code.
>
>> I don't have answers to those questions, but I sure hope they're on
>> somebody's radar, because you've got a real, systemic issue here that is
>> right-now-today actively fragmenting Mozilla's most important repository
>> of self-knowledge. And that's happening at the same time that the
>> organization is growing like mad.
>
> It's sort of on the radar. But what's the fix?

I think you've answered your own question there, but if you've
discounted a policy championed by somebody near the top level of the
organization, I don't see another answer. And my experience is that this
type of fragmentation only gets worse. It never gets better.

Maybe I'm wrong? Maybe this is all no big deal, somebody can gin up a
few import/exports scripts that hook into GitHub or whatever the next
CMS coming down the pipe is and tie it all together, and everyone can
fork their own bugzilla front end and it will all be fine.

But I don't think so. And the cost a policy that consolidates Mozilla's
issue tracking and the cost of making Bugzilla more user-accessible this
year will be a vanishing fraction of what it costs to do all that plus
(inevitably) consolidating a fractured development process and community
in 2017.

[i...@paulbooker.co.uk]

On 11/04/2012 15:42, Gervase Markham wrote:
> On 10/04/12 18:44, Mike Hoye wrote:
>> I've received this via email from a few other people as well. I've read
>> it a few times now, and I'm trying to figure out if there's a more
>> charitable way to interpret it than "If you don't like the bugzilla
>> interface, write your own.
>
> That's basically what it is. Several people have. :-) We can't make
> the UI all things to all people - that's why I wrote BzAPI. That
> doesn't mean it can't be improved, but it does mean that the quickest
> route to happiness for any one particular group may be to write their
> own tool.
>
>> Patches accepted maybe, but probably not."
>
> If it's just an alternative template view for a bug, I don't see any
> reason the patch wouldn't be accepted.
>
>> Why are they all over there? I mean, git, sure. Git's awesome. But why
>> is all the issue tracking stuff over there too?
>
> Integration, I suspect. Path of least resistance.
>

Totally agree (and with previous comments). I think Mozilla should have
a conversation with the
community about how we currently use social services and if we could do
better. Personally I
think we should try to have all our services running on our own servers.

>> Is it because there's no formal policy about where Mozilla's bugs go, or
>
> I think it's more that there was an sort of assumed and therefore
> unwritten policy about where Mozilla code goes, but it was unwritten
> and therefore as we expanded, didn't get followed. And the bugs have
> followed the code.
>
>> I don't have answers to those questions, but I sure hope they're on
>> somebody's radar, because you've got a real, systemic issue here that is
>> right-now-today actively fragmenting Mozilla's most important repository
>> of self-knowledge. And that's happening at the same time that the
>> organization is growing like mad.
>
> It's sort of on the radar. But what's the fix? The "don't use github"
> horse has left the stable, left the village, and recently crossed the
> state line still going at a furious clip. Moving everything to github
> would be an enormous project and we'd be taking on some big risks. So
> what do we do?

:) I think all we can do is have our own Git server, educate the
community on the issues involved and leave it in the communities hands
>
> Gerv

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

--
[+] Paul Booker - MCS | Mozilla UK Community Member - Drupal Developer | Systems administrator
[+] WebFWD Scout
[+] T: @paulbooker

[i...@paulbooker.co.uk]

+1
>
> Robert Kaiser

[Justin Wood (Callek)]

I had a similar discussion the other day about why B2G issues are being
tracked in github! Where I didn't seem to get much headway with the one
I was discussing with.

That said, I think this general overarching topic needs to be broken out
to a separate thread, with its own discussion/debate/points/etc
completely separately.


--
~Justin Wood (Callek)

[Robert Helmer]

These are important points. I use github for many Mozilla projects, and
share all the same concerns.

In defense of github - Mozilla does not exist in a vacuum, but in a
world of other open-source and proprietary (and many in-between!)
projects. People involved with these projects wish to work with us, and
us with them, although they will not necessarily become part of the
Mozilla Community.

Two examples I am personally familiar with are Socorro (aka
crash-stats.m.o) which has many installations by people not otherwise
affiliated with Mozilla, and Perf-o-Matic (aka graphs.m.o) which is used
by (at least) WebKit. Both of these Mozilla projects use github,
although graphs is a mirror (hg.m.o/graphs is considered canonical.)
Both projects use Bugzilla exclusively for issue tracking. When we get a
pull request without an affiliated bug, we file one in bugzilla on the
contributor's behalf. I merge to the graphs github repo manually.

The road to contributing a patch to traditionally-hosted Mozilla
projects can be quite daunting compared to the UX of a github pull
request, and I believe that this both makes Mozilla projects harder to
discover and the overall bar to contribute is higher. github's issue
tracker is much simpler (and conversely, has fewer features) than
bugzilla, and many more developers already have github accounts and are
familiar with it's issue tracker (or can figure it out without much fuss.)

I can appreciate the choice github-the-company is making to fund a
high-quality product through charging for private repositories and
installs, which I assume are mostly for proprietary software. There is
definitely a risk here that they need to change strategy, are acquired,
or that some other event could have a big impact on us if our workflow
and information are heavily invested in github.

For git repositories, I believe we already have reasonable hedges in place:

* http://gitmirror.mozilla.org/ is available as an automatic mirror
* everybody who has cloned has a full copy of the project (recovering in
this way does not sound particularly fun, compared to the mirror)

However, for things such as review comments and issues those would
indeed be lost unless some special action was being taken (I believe
everything is available via the github API [1] but I don't know of
anyone actively mirroring this.)

One technical way forward might be to build a new project management/bug
tracker UI that sits atop the bugzilla and github APIs, in the spirit of
solving all problems in computer science by adding another level of
indirection ;)

It strikes me that Mozilla has a need to track, integrate and contribute
to many upstream projects, as well as tracking our own projects, so
having something like this might actually be sensible. The Canonical
Launchpad [2] project has some similarities in that it can track
upstream bugs, but I think it's built with very different goals in mind
so probably not directly applicable.

[1] http://developer.github.com/v3/
[2] http://en.wikipedia.org/wiki/Launchpad_%28website%29

[Robert Kaiser]

Robert Helmer schrieb:

> However, for things such as review comments and issues those would
> indeed be lost unless some special action was being taken (I believe
> everything is available via the github API [1] but I don't know of
> anyone actively mirroring this.)

If the API makes them available, that's already a good step.

> One technical way forward might be to build a new project management/bug
> tracker UI that sits atop the bugzilla and github APIs, in the spirit of
> solving all problems in computer science by adding another level of
> indirection ;)

Hmm, feeding comments and issues into Bugzilla via their API might be
interesting indeed...

Robert Kaiser

[Dave Mandelin]

It sounds like you are basically saying that github is better for coordination and co-development with 'external' people, such as WebKit devs and new contributors.

Are there more reasons to use github? In particular, I'm wondering if certain people or teams just find it better than hg+bugzilla for day-to-day work.

> I can appreciate the choice github-the-company is making to fund a
> high-quality product through charging for private repositories and
> installs, which I assume are mostly for proprietary software. There is
> definitely a risk here that they need to change strategy, are acquired,
> or that some other event could have a big impact on us if our workflow
> and information are heavily invested in github.
>
> For git repositories, I believe we already have reasonable hedges in place:
>
> * http://gitmirror.mozilla.org/ is available as an automatic mirror
> * everybody who has cloned has a full copy of the project (recovering in
> this way does not sound particularly fun, compared to the mirror)
>
> However, for things such as review comments and issues those would
> indeed be lost unless some special action was being taken (I believe
> everything is available via the github API [1] but I don't know of
> anyone actively mirroring this.)

Good points. So it seems like there aren't any disasters to worry about, just a risk of substantial disruption to the affected projects if the issues were to get lost.

> One technical way forward might be to build a new project management/bug
> tracker UI that sits atop the bugzilla and github APIs, in the spirit of
> solving all problems in computer science by adding another level of
> indirection ;)

Not sure exactly what the wink means. I'm skeptical that something like that could be made to work particularly well, at least without a major investment to build and a substantial continuing maintenance effort.

> It strikes me that Mozilla has a need to track, integrate and contribute
> to many upstream projects, as well as tracking our own projects, so
> having something like this might actually be sensible. The Canonical
> Launchpad [2] project has some similarities in that it can track
> upstream bugs, but I think it's built with very different goals in mind
> so probably not directly applicable.
>
> [1] http://developer.github.com/v3/
> [2] http://en.wikipedia.org/wiki/Launchpad_%28website%29

I think the whole situation and discussion around github is symptomatic of the fact that people think our existing tools are just not keeping up with either our needs, or what's possible with current technology; or maybe that we're just not talking enough as a community about what to do.

If our tools vs. github are a major barrier to attracting contributors or doing our own work, that seems like a major problem. If they are not a major barrier to anything, then having different teams run off and create incompatible trees and issue databases seems like a major problem. So I'm pretty convinced that the current situation is not good.

[Robert Helmer]

On 4/16/12 1:38 PM, Dave Mandelin wrote:
> On Friday, April 13, 2012 4:27:18 PM UTC-7, Robert Helmer wrote:
>> The road to contributing a patch to traditionally-hosted Mozilla
>> projects can be quite daunting compared to the UX of a github pull
>> request, and I believe that this both makes Mozilla projects harder to
>> discover and the overall bar to contribute is higher. github's issue
>> tracker is much simpler (and conversely, has fewer features) than
>> bugzilla, and many more developers already have github accounts and are
>> familiar with it's issue tracker (or can figure it out without much fuss.)
>
> It sounds like you are basically saying that github is better for coordination and co-development with 'external' people, such as WebKit devs and new contributors.
>
> Are there more reasons to use github? In particular, I'm wondering if certain people or teams just find it better than hg+bugzilla for day-to-day work.

I personally feel that github+git is a better UX for development in
general compared to bugzilla+patches, and a big part of that is the
learning curve. Many devs already happen to use gitub. Plain old git
versus hg is way more subjective.

>> For git repositories, I believe we already have reasonable hedges in place:
>>
>> * http://gitmirror.mozilla.org/ is available as an automatic mirror
>> * everybody who has cloned has a full copy of the project (recovering in
>> this way does not sound particularly fun, compared to the mirror)
>>
>> However, for things such as review comments and issues those would
>> indeed be lost unless some special action was being taken (I believe
>> everything is available via the github API [1] but I don't know of
>> anyone actively mirroring this.)
>
> Good points. So it seems like there aren't any disasters to worry about, just a risk of substantial disruption to the affected projects if the issues were to get lost.

All the projects I work on rely quite heavily on bugzilla, and it'd be
pretty devastating for me if it all just went away one day. I find it
super critical for ongoing work as well as archeological expeditions, so
I'd imagine losing a substantial base of github issues and review
comments would be similar.

>> One technical way forward might be to build a new project management/bug
>> tracker UI that sits atop the bugzilla and github APIs, in the spirit of
>> solving all problems in computer science by adding another level of
>> indirection ;)
>
> Not sure exactly what the wink means. I'm skeptical that something like that could be made to work particularly well, at least without a major investment to build and a substantial continuing maintenance effort.

(the wink is just me congratulating myself on a clever reference)

I agree. Project management and issue tracking are a lot of work, and it
never ends (or at least lasts about as long as the project!)
github and bugzilla have both had and continue to have substantial
investment.

We'd need to decide what our current problems are, and whether they're
worth fixing, before trying to apply a technical solution.

>> It strikes me that Mozilla has a need to track, integrate and contribute
>> to many upstream projects, as well as tracking our own projects, so
>> having something like this might actually be sensible. The Canonical
>> Launchpad [2] project has some similarities in that it can track
>> upstream bugs, but I think it's built with very different goals in mind
>> so probably not directly applicable.
>>
>> [1] http://developer.github.com/v3/
>> [2] http://en.wikipedia.org/wiki/Launchpad_%28website%29
>
> I think the whole situation and discussion around github is symptomatic of the fact that people think our existing tools are just not keeping up with either our needs, or what's possible with current technology; or maybe that we're just not talking enough as a community about what to do.
>
> If our tools vs. github are a major barrier to attracting contributors or doing our own work, that seems like a major problem. If they are not a major barrier to anything, then having different teams run off and create incompatible trees and issue databases seems like a major problem. So I'm pretty convinced that the current situation is not good.

Personally I feel that hg, bugzilla, etc. are not a major barrier for a
motivated contributor. I have no way to measure how many more casual
contributions we might have received if it was a little easier, I can
say that I get more random unsolicited github pull requests than I do
bugzilla patches from non-mozillians.

github-the-company has been directing energy at making a great product
for a while now, so I think that's really hard for others to keep up
with and I don't feel too threatened that some of our infra is a bit
lackluster in comparison (we have some nice bells and whistles too that
they don't match, like tbpl and try and perf, dependencies in bugzilla,
etc.)

I think we have good reasons for not putting all of our eggs in the
github basket, but we should definitely learn from them and use their
service as appropriate.

I've found the hg-git plugin pretty handy for merging things between
hg.m.o/github, and for projects that mandate "though shalt use hg +
bugzilla" it's not too hard to just have github "on the side" for
working with contributors.

[Robert O'Callahan]

On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin <dman...@mozilla.com>wrote:

> If our tools vs. github are a major barrier to attracting contributors or
> doing our own work, that seems like a major problem. If they are not a
> major barrier to anything, then having different teams run off and create
> incompatible trees and issue databases seems like a major problem. So I'm
> pretty convinced that the current situation is not good.
>

As far as I can tell our tools and infrastructure are better than they've
ever been. Maybe other tools and infrastructure are better, but I don't
think anyone can claim our tools and infrastructure are "a major barrier to
doing our own work".

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]

[David Dahl]

----- Original Message -----
> From: "Robert O'Callahan" <rob...@ocallahan.org>
> To: "Dave Mandelin" <dman...@mozilla.com>
> Cc: dev-pl...@lists.mozilla.org, "Damon Sicore" <dsi...@mozilla.com>
> Sent: Tuesday, April 17, 2012 4:34:21 AM
> Subject: Re: Mozilla's use of github (was Re: Bug Importance)
>
> On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin
> <dman...@mozilla.com>wrote:
>
> > If our tools vs. github are a major barrier to attracting
> > contributors or
> > doing our own work, that seems like a major problem. If they are
> > not a
> > major barrier to anything, then having different teams run off and
> > create
> > incompatible trees and issue databases seems like a major problem.
> > So I'm
> > pretty convinced that the current situation is not good.
> >
>
> As far as I can tell our tools and infrastructure are better than
> they've
> ever been. Maybe other tools and infrastructure are better, but I
> don't
> think anyone can claim our tools and infrastructure are "a major
> barrier to
> doing our own work".
>

+1

It would be interesting if we could gather metrics on community contribution about our github projects. I get the feeling that Github usage *might* be a catalyst for more community participation but there is no hard evidence (that I have seen) to indicate this.

Regards,

David

[Philip Chee]

On Tue, 17 Apr 2012 21:34:21 +1200, Robert O'Callahan wrote:
> On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin <dman...@mozilla.com>wrote:
>
>> If our tools vs. github are a major barrier to attracting contributors or
>> doing our own work, that seems like a major problem. If they are not a
>> major barrier to anything, then having different teams run off and create
>> incompatible trees and issue databases seems like a major problem. So I'm
>> pretty convinced that the current situation is not good.
>>
>
> As far as I can tell our tools and infrastructure are better than they've
> ever been. Maybe other tools and infrastructure are better, but I don't
> think anyone can claim our tools and infrastructure are "a major barrier to
> doing our own work".

However they might be a major barrier (learning curve, paradigm shift)
to people familiar with the github workflow.

[Mike Hoye]

On 12-04-17 5:34 AM, Robert O'Callahan wrote:
> On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin <dman...@mozilla.com>wrote:
>

>> If our tools vs. github are a major barrier to attracting contributors or
>> doing our own work, that seems like a major problem. If they are not a
>> major barrier to anything, then having different teams run off and create
>> incompatible trees and issue databases seems like a major problem. So I'm
>> pretty convinced that the current situation is not good.
>>
>

> As far as I can tell our tools and infrastructure are better than they've
> ever been. Maybe other tools and infrastructure are better, but I don't
> think anyone can claim our tools and infrastructure are "a major barrier to
> doing our own work".

Nobody has made that claim, and it is a very different claim than the
one that kicked off this discussion. The conversation that kicked this
off was an observation that:

- no two people or teams are using bugzilla the same way, and that this
is starting to cause internal communication problems.

The two major followup points I made in that thread were that:

- One symptom of those communication problems is that Bugzilla presents
a real barrier to participation for new contributors, and

- The increasing use of GitHub's private issue tracking and
closed-source development workflow as a Bugzilla/hg alternative puts
Mozilla at risk of a fractured development community and potentially
real information loss.

If any of those three are false or simply not a good time/value tradeoff
to address then they should not be addressed. If they're not an
organizational priority, doing nothing is the right thing. I think they
should be; I may be wrong.

But this is not (and should not become) a discussion about whether or
not somebody's been doing a second-rate job in some aspect of developer
support; it's about some larger internal and external communication
issues that Mozilla faces that happen to touch, among other things,
developer tools.

[Mike Connor]

On 2012-04-17, at 10:55 AM, Philip Chee wrote:

> On Tue, 17 Apr 2012 21:34:21 +1200, Robert O'Callahan wrote:
>> On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin <dman...@mozilla.com>wrote:
>>
>>> If our tools vs. github are a major barrier to attracting contributors or
>>> doing our own work, that seems like a major problem. If they are not a
>>> major barrier to anything, then having different teams run off and create
>>> incompatible trees and issue databases seems like a major problem. So I'm
>>> pretty convinced that the current situation is not good.
>>>
>>
>> As far as I can tell our tools and infrastructure are better than they've
>> ever been. Maybe other tools and infrastructure are better, but I don't
>> think anyone can claim our tools and infrastructure are "a major barrier to
>> doing our own work".
>
> However they might be a major barrier (learning curve, paradigm shift)
> to people familiar with the github workflow.

I think it's all well and good to cite "I get lots of pull requests on Github!" as a rationale, but we've been doing it for long enough that we should probably pull some stats. Like… how many pull requests do projects get from "outside" contributors vs. team members?

-- Mike

[Robert O'Callahan]

On Wed, Apr 18, 2012 at 3:11 AM, Mike Hoye <mh...@bespokeio.com> wrote:

> - no two people or teams are using bugzilla the same way, and that this
> is starting to cause internal communication problems.
>

No two people or teams use Bugzilla the same way? It seems to me that I and
the teams I work with have been using Bugzilla consistently for several
years now.

Maybe you meant "not all people or teams".

[Robert O'Callahan]

On Wed, Apr 18, 2012 at 2:55 AM, Philip Chee <phili...@gmail.com> wrote:

> However they might be a major barrier (learning curve, paradigm shift)
> to people familiar with the github workflow.
>

Learning a new workflow is normal when entering a large open source
project. Most large projects have their own infrastructure and workflow
that's not github's. Many large projects have a workflow that's much more
like ours than github.

So, smoothing the path for github users sounds like a good thing, but it's
more of an opportunity than a problem IMHO.

[Justin Lebar]

On Wed, Apr 18, 2012 at 1:37 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Wed, Apr 18, 2012 at 2:55 AM, Philip Chee <phili...@gmail.com> wrote:
>

>> However they might be a major barrier (learning curve, paradigm shift)
>> to people familiar with the github workflow.
>>
>

> Learning a new workflow is normal when entering a large open source
> project. Most large projects have their own infrastructure and workflow
> that's not github's. Many large projects have a workflow that's much more
> like ours than github.
>
> So, smoothing the path for github users sounds like a good thing, but it's
> more of an opportunity than a problem IMHO.

I don't want us to ignore the things we *can* learn from github.

It's fast. It's pretty. It's integrated with SCM.

It doesn't have mid-air collisions, or accidental modification of
flags. You can reply to bugmail straight from your e-mail client.
Code review is integrated into the system.

Did I mention it's fast?

"Our workflow is not so hard to learn compared to the inherent
difficulty of hacking on Firefox" is, I think, a completely valid
point to make. But on the other hand, I don't think we should write
off the pain that people are feeling or the benefits they see in
github.

[Mike Hoye]

On 12-04-17 11:30 PM, Robert O'Callahan wrote:
>
>
> Maybe you meant "not all people or teams".

No, I meant "no two people or teams."

Following the discussion in the "bug importance" thread, I did some
hallway usability testing, and stood in the kitchen in MoTo and asked
anyone walking past how they used Bugzilla.

Everyone I spoke to had roughly the same answer: "My team uses it like
this and ignores everything else. I use this other flag that my team
ignores, for my own reasons." The specific flags and features were
always different.

All told I spoke to about a dozen people; it was interesting to see
people on the same team compare notes about how they both do things
differently but still manage to avoid stepping on each others' toes.

The most fascinating thing is, all that understanding is just completely
ethereal; it's not written down anywhere, people say they just soaked it
up over time as they work with their teams. The implication is that
there isn't just one bugzilla workflow, that may present a challenge for
new contributors - there are dozens of little bugzilla-workflow
dialects, and no way to know which team speaks which one.

[Chris Pearce]

On 19/04/2012 1:53 a.m., Mike Hoye wrote:
> On 12-04-17 11:30 PM, Robert O'Callahan wrote:
>>
>>
>> Maybe you meant "not all people or teams".
>
> No, I meant "no two people or teams."
>
> Following the discussion in the "bug importance" thread, I did some
> hallway usability testing, and stood in the kitchen in MoTo and asked
> anyone walking past how they used Bugzilla.
>
> Everyone I spoke to had roughly the same answer: "My team uses it like
> this and ignores everything else. I use this other flag that my team
> ignores, for my own reasons." The specific flags and features were
> always different.

Why do you think GitHub will be immune to feature usage
drift/divergence? (re: flags & features, not pull requests obviously)

It seems to me (based on only using GitHub for a few of my own small
projects) that the only way to mark/flag an "issue" in GitHub is to
either comment or add a label?

Granted our bugzilla instance has lots of flags used different ways by
different people. But I'm sure if we started using GitHub issues instead
of bugzilla we'd end up using a plethora of labels in the place where we
now use the various bugzilla flags and we'd end up with the same problem.

> The most fascinating thing is, all that understanding is just completely
> ethereal; it's not written down anywhere, people say they just soaked it
> up over time as they work with their teams.

Then maybe we should standardize and write it down and link to it in
such a way that new/prospective contributors are likely to find it?

Regardless we'd still have this problem r.e. flags/labels if we moved to
GitHub, and we'd still need to write it down somewhere.


Chris P.

[Mike Hoye]

On 12-04-18 7:57 PM, Chris Pearce wrote:
> Why do you think GitHub will be immune to feature usage
> drift/divergence? (re: flags & features, not pull requests obviously)

I don't. In fact, I think that the feature/usage drift is both
inevitable and desirable with a complex tool in a large organization.
It's hard to see "Mozilla is now big enough to have several different
internal cultures" as anything but a positive, and regional dialects are
an artefact of a large population. Seems like a victory condition, and
nothing is going to change that.

I am making only two claims:

- That the Bugzilla front-end should be refactored, to some extent, with
an understanding that teams-dialects exist and a way to make those team
dialects explicit for other people, rather than the ethereal "everyone
kind of knows" understanding people have now. I believe that this will
have lasting benefits beyond internal communications issues.

- That the increasing reliance on a closed-source third-party
development workflow and issue tracking package is exposing Mozilla to a
risk of significant real dataloss, and that risk is not currently being
addressed. I believe that this risk is being assumed not out of any
explicit decision, but just because it's quietly happening and nothing's
gone horribly wrong yet. Which is another way of saying "without any
analysis, contingency planning or any one group assuming responsibility".

If GitHub goes dark tomorrow, what happens? Is all that information just
gone?

[Robert O'Callahan]

On Thu, Apr 19, 2012 at 1:53 AM, Mike Hoye <mh...@bespokeio.com> wrote:

> Following the discussion in the "bug importance" thread, I did some
> hallway usability testing, and stood in the kitchen in MoTo and asked
> anyone walking past how they used Bugzilla.
>
> Everyone I spoke to had roughly the same answer: "My team uses it like
> this and ignores everything else. I use this other flag that my team
> ignores, for my own reasons." The specific flags and features were always
> different.
>

> All told I spoke to about a dozen people; it was interesting to see people
> on the same team compare notes about how they both do things differently
> but still manage to avoid stepping on each others' toes.
>

> The most fascinating thing is, all that understanding is just completely
> ethereal; it's not written down anywhere, people say they just soaked it up

> over time as they work with their teams. The implication is that there
> isn't just one bugzilla workflow, that may present a challenge for new
> contributors - there are dozens of little bugzilla-workflow dialects, and
> no way to know which team speaks which one.

I see lots of Bugzilla activity from lots of teams (even legal and HR) and
lots and lots of developers and I never feel bothered that they're using
Bugzilla differently to the way I do. I guess these differences just don't
matter to me.