120481 - [trial] change Network Component default owner to [e-mail]

Status: VERIFIED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[general]

I'll do it!

Comment 1

[[e-mail]]

(okay, this needs more explaination... which I'll do as soon as I get a chance...)

Comment 2

[[e-mail]]

This request got more attention than I would have imagined. The original idea
was that Asa and I were going to use networking as a proving ground for several
new bug management processes. We thought networking had enough solid
contributors and a track record for innovation, plus most of the ideas were my
suggestion, so I should eat my own dogfood if I was wrong...

What we did not expect, was that so many people would notice. My mistake, you
can send your concerns to me rather than Asa. I've already talked to timeless
about this change.

Here's the idea:

Change the default owner of a component from a specific engineeer to a
component-named email account.

Benefits:
1- Allow bugzilla contributors to track incoming bugs for the component by using
watch feature.

Right now, the owner is neeti, the qa is benc. If you follow the email of either
of us, you will get a ton of email from other components. 

If you run daily bugzilla queries, you have to update by bug number every day
(to get the new slice bugs in time), and you can't defer looking at bugs easily
(because you have to remember which ones you skippeed).

Contributors are more likely to get involved if we can give them focus. Since
they do not get paid to work on mozilla, forcing contributors to read lots of
extra bugmail or run daily bugzilla queries is inconsiderate to the time
constraints of contributors.

Note: Component level bug tracking is on the to do list, but this change is
still desirable because: 1- it happens now, 2- the suggested email account is
configured to receive only "new" notices of bug creations.

2- Provides separation between two stages of "triage"

Triage is considered by some to be the problem definition of incoming bugs.
Others consider it the process by which code contributors prioritize and
milestone fixes. People are usually only involved in one, not the other.
Ironically, people involved with triage #1 say "triage is being held up because
nobody is prioritizing and milestoning their bugs". Simulatenously, people
involved in #2 often feel "triage would go faster if people would clean up their
problem descriptions and steps to reproduce..." People invlovled in both
probably say "wow there are a ton of bugs coming in, and I have too much work to
do..."

I have proposed several alternative terms, for now, I'm going to say "bug
submission triage" and "fix ordertriage". Less than ideal, but sufficient for now.

This will give contributors interested in bug sumission triage a specific target
(or queue) that can be found with a query. From here, we can provide
documentation and information to improve this process (like checking for
duplicates, checking multiple platforms, confirming steps to reproduce, etc.)

3- Speed "fix order triage" by improving signal-noise ratio.

When a sumbission is considered well-defined, the bug can be keyworded
"helpwanted". Gagan (manager of necko engineers) has suggested this should be
the interim way of flagging bugs that are "ready".

This is a transitional experiment. Currently, necko engineers (darin, dougt,
gordon, neeti) have participated in both triages. The goal is to reduce
community dependence on them for submission triage. Initially, their
participation may not change, hopefully it will decrease over time.

Engineers retain the right to "take" bugs at any time (fast track).
Bugs that require their assistance w/ triage can be cc'd to anyone (consultation).
Bugs in this component can be assigned to neeti if they are severe (escalation).

3- Improve fix rate by reducing bug management overhead for engineering.

Less submission triage, less bug mail, and better bugs should make fix order
triage take less time and have more value. This means fewer meetings, more coding.

Comment 3

[[e-mail]]

Possible cons:
Some people have expressed concerns about a lack of individual ownership of
sumbitted bugs. This is a problem, but not a valid objection to the proposal.

1- This confuses owenership vs. responsibility. Engineers should not own for
sumbission triage. Engineers own code contributions. As team players, they
should be responsible for helping the community triage submissions. Some
individuals may wish to do both, but the engineering role does not own
sumbisssions. 

2- This ownership of a bug submission belongs to the reporter, not the "default
owner".

Until a problem description is well definied, it would beg the question to say
an engineer owns fixing it.

The reality is that a bug has three major owners in its life cycle: 1- reporter
(for sumbission and definition), 2- engineer|"assigned" (for fix and resolution)
and 3- QA (verification and documentation).

The second major objection was the email address selected
"[e-mail]".

This might give the appearence that packetgram is trying to take over various
networking qa or networking bug management activities.

Nothing of the sort is happening. We needed an email address to start this
experiment. Since this is experimental, mozilla.org did not seam suitable. Since
this is a community effort, netscape.com was not appropriate either. Since
packetgram.com is a site that supports networking standards and interoperability
in any way it can, I donated the email address.

If this is a success, packetgram will definitely insist on a more appropriate
sounding permanent name.

Comment 4

[[e-mail]]

One final note:
The new ownership and its effects on bug triage apply only to "Networking". If a
bug is moved to any other component, revert to the status quo method of handling it.

Comment 5

[Pete Collins (MDG)]

Sounds like a good idea to me. Why only netwerk module though?

A a contributor, i have my regular list of bugs "to fix" which i work on when i can.
However, any contributions i've made here in the the netwerk module were
happened by chance or emails from friends complaining about a particular bug. I
didn't go looking for netwerk bugs, they came to me.  

I don't have time to do daily queries of bugzilla looking for new crashers etc.
But i enjoy fixing them.

I do like it when someone cc's me on a bug that i can help out on and if i can,
i'm happy to do so.

It is a lot wasted mental overhead managing bugs. I certainly is much more
enjoyable fixing them.

--pete

Comment 6

[[e-mail]]

My goal is to focus on making a lot of good changes in a controlled environment,
then try to build critical mass to expand those improvements to the other
components.

Since you are interested in fixes more than the general incoming bug flow, I'll
start to work on the changes I had in mind for people like you, fix-oriented
people. 

The growing consensus is to start using "helpwanted" more liberally.

Comment 7

[Asa Dotzler [:asa]]

fixed.

Comment 8

[Asa Dotzler [:asa]]

fixed

Comment 9

[timeless]

vrfy fixed. i'll try to look in on this in 1-3 months.

Comment 10

[[e-mail]]

Update:

I was unaware of bug 74996.
If you "watch" this email account, you will probably get everything.

I am testing this to see if one of the other filter options is hooked in
(probably cc?), and will add results here.