Bugzilla Administration Ideas

[Herbert Duerr <hd...@apache.org>]

I'm starting a thread on what should be done in our Bugzilla.

Here are some ideas:

- remove fields that confuse more than they help to describe or solve 
the problem, e.g. the fields "Hardware"

- reduce field choices, e.g. for the field "OS" the options "Windows 
3.1", "Mac System 7" or "OpenVMS" should go

- if the default owner of a component is no longer active in the project 
then that should be changed to a generic name

- if it is possible at all then add a hierarchy to the components, e.g. 
all the localization projects should go into a l10 group, e.g. l10/ja

- if it is possible to reduce the choice of impacted versions when a new 
issue is entered then that should be done. Bugs reported against ancient 
milestones such as 644m11 are just not interesting

Herbert

Re: Bugzilla Administration Ideas

[TJ Frazier <tj...@cfl.rr.com>]

On 1/24/2012 10:19, Herbert Duerr wrote:
> I'm starting a thread on what should be done in our Bugzilla.
>
> Here are some ideas:
>
> - remove fields that confuse more than they help to describe or solve
> the problem, e.g. the fields "Hardware"
>
> - reduce field choices, e.g. for the field "OS" the options "Windows
> 3.1", "Mac System 7" or "OpenVMS" should go
>
> - if the default owner of a component is no longer active in the project
> then that should be changed to a generic name
>
> - if it is possible at all then add a hierarchy to the components, e.g.
> all the localization projects should go into a l10 group, e.g. l10/ja
>
> - if it is possible to reduce the choice of impacted versions when a new
> issue is entered then that should be done. Bugs reported against ancient
> milestones such as 644m11 are just not interesting

Here there is a small problem. We need to know, eventually, two 
different version numbers: the earliest version that shows the problem, 
and the latest version tested. In the past, the "reported" version was 
supposed to be the earliest ("oo.o 3.2.1"), and the user should add 
something like, "also fails under 3.4 Beta". We could do a better job of 
making this clear, or maybe we need another field, or both.
  /tj/
>
> Herbert
>
>

Re: Bugzilla Administration Ideas

[Rob Weir <ro...@apache.org>]

On Tue, Jan 24, 2012 at 10:19 AM, Herbert Duerr <hd...@apache.org> wrote:
> I'm starting a thread on what should be done in our Bugzilla.
>
> Here are some ideas:
>
> - remove fields that confuse more than they help to describe or solve the
> problem, e.g. the fields "Hardware"
>
> - reduce field choices, e.g. for the field "OS" the options "Windows 3.1",
> "Mac System 7" or "OpenVMS" should go
>
> - if the default owner of a component is no longer active in the project
> then that should be changed to a generic name
>
> - if it is possible at all then add a hierarchy to the components, e.g. all
> the localization projects should go into a l10 group, e.g. l10/ja
>

What we have today, for example, is:

product: aa ("Afar Language Project: Work in and on the Afar language")

And within product aa we have a single component, "www"

Each product also has an admin group and a dev group.  Since we have
so many languages we end up with hundreds of groups and components.

This gives very fine grained control, but I wonder if it is entirely
overkill.  For example, we have no Afar Language bugs at all.

What might make more sense in an Apache project is to have a much
"flatter" view of the world and project participants.  So permissions
are:

-- Admins (all rights)
-- Committers (editbugs)
-- Registered Users (default base permissions)

If we do this we could eliminate hundreds of permission groups.

Some products can simple go away, like "council",etc.

Versions are per product not per component, so I imagine it is
currently laborious for someone to enter a new version, since they
need to add it for each product, Calc, Writer, etc., separately.
Maybe just have a single base product "OpenOffice" and make the apps
each be components.  We could do a similar thing for languages.

So a hierarchy like this:

Product: OpenOffice Application
Components: Calc, Writer, Impress, etc.

Product: Localization
Components: aa, af, ... zh

Product:  Website
Components: Forums, Blog, Bugzilla, Wiki, etc

Product: Documentation
Components: Help, Manuals, FAQ's, etc.


So something like that.  Reduce 100's of components and permission
groups into < 10 main products, each one with a handful of components,
something that any user can understand.

> - if it is possible to reduce the choice of impacted versions when a new
> issue is entered then that should be done. Bugs reported against ancient
> milestones such as 644m11 are just not interesting
>
> Herbert