incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Bugzilla Administration Ideas
Date Tue, 24 Jan 2012 17:44:20 GMT
On Tue, Jan 24, 2012 at 10:19 AM, 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

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

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

View raw message