incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regina Henschel <>
Subject Re: [PROPOSAL] Bugzilla Cleanup
Date Thu, 26 Jan 2012 18:24:32 GMT
Hi Rob,

Rob Weir schrieb:
> I'd like to make some changes to our bug tracker, to make it more
> user-friendly.  Since these changes are not easily reversible, I'd
> like to describe them first, to see if anyone has objections.
> 1) Convert legacy language project "products" into "components" under
> the "native-lang" product.  I'll ensure that all existing bugs
> previously classified under a language project code are reclassified
> into the new structure.


> 2) Create a new "comitters" group in BZ, with additional permissions
> like "editbugs" and "canconfirm"  AOO committers will be added to this
> group, on request. I can't do it automatically, since your BZ login
> might be different than your Apache ID.

I do not like the term "commiter" here. BZ user with additional 
permissions are more "quality assistant". And do they really need to be 
commiters with Apache ID? I think not.

> 3) Delete obsolete "products" like bizdev and council.

What will happen with the associated issues? Suggestion: A product 
"legacy" with all of them under components. It should not be available 
in the form for new issues, but only in advanced search. And all of 
their issues should be "closed".

> 4) Delete the permission groups associated with the removed products.


> 5) Remove default owners for components.   Most of this information is
> obsolete in any case, with owners being people no longer involved with
> the project.  This will be easy for any comitter to add back, if they
> want to volunteer to own issues in a given category.  But maybe we
> don't even want "owners"?

A "owner" is meaningful. But it should be that person, that is actually 
working on that issue. You are right, that there need not to be default 
owners for each component, but one default owner is sufficient something 
like "untreated task".

> 6) End result is a much flatter structure.  Instead of hundreds of
> different permission groups corresponding to 100's of different
> components, we have admins, committers, and users.  Admins and
> committers can modify all bugs, regardless of components.
> 7) One objection might be, but what if we have a user who needs to
> regularly modify many bugs, to help move them through the workflow,
> someone who is helping us clean up bugs, correcting classifications,
> verifying issues for us, etc.  Won't they be locked out of doing this
> administrative tasks?  My response is simple:  We should be making
> such users into committers based on that level of contribution.

I disagree here. The only question is, whether she/he does a good job on 
BZ. For example identify duplicates, sort out support requests, collect 
missing information. You should invite them, but do not set it as 

I miss a cleanup of the "version" list box.
(1) Do not show developer versions, which are superseded be a released 
version. But bundle them to one item, when the corresponding release is 
(2) The purpose of "version" is unclear for users. They tend to use it 
in the kind "I still see it in version ...", although it has been 
planned to be "Bug was _first_ seen in ...". So the title should be 
(3) Show only actual versions in the form for new issues. A user should 
not report a problem for a version, which will never have a bug-fix 
release. See

Remove the field "priority". Reasoning: (1) Numbers do not tell whether 
a 1 has more priority than a 5 or the other way round.(2) Priority has 
no effect in resolving. (3) Severity is enough for classification.

Combine OS and Hardware to one list. Show only OS in the list, which are 
actually supported. For all other problems a category "other" is sufficient.

Kind regards

View raw message