incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: [PROPOSAL] Bugzilla Cleanup
Date Thu, 26 Jan 2012 18:42:20 GMT
Hi Regina;

--- Gio 26/1/12, Regina Henschel <rb.henschel@t-online.de> ha scritto:

> 
> 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.
> 

The term is indeed somewhat misunderstood. Committer in
Apache means someone involved with the project. Write
access to SVN is one thing that comes with becoming a
committer but it's not something committers are expected
to do. 

Formal committers get access not only to SVN but also to
edit wikis and other apache infrastructure that normal
users cant. We do have plenty of committers that are not
doing changes to the code but that are working on the
webpages or the wikis or simply contributing by email.

While privileges for the bugzilla instance were transferred
along with the database, this was a one time thing that
will likely have to be adjusted. I would expect that from
now on the only way to get such privileges is after
becoming a formal committers.

Becoming a committer is no huge mystery as one may think.

cheers,

Pedro.


> > 
> > 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.
> 
> +1
> 
> > 
> > 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 prerequisite.
> 
> 
> 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 done.
> (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 enhanced.
> (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 https://issues.apache.org/ooo/show_bug.cgi?id=88964
> 
> 
> 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
> Regina
> 

Mime
View raw message