openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Bugzilla -- Any interest in enabling "categories"?
Date Tue, 05 Feb 2013 23:41:43 GMT

On Feb 5, 2013, at 3:23 PM, Rob Weir wrote:

> On Tue, Feb 5, 2013 at 6:06 PM, Dave Fisher <> wrote:
>> On Feb 5, 2013, at 1:43 PM, Rob Weir wrote:
>>> On Tue, Feb 5, 2013 at 4:22 PM, Regina Henschel <>
>>>> Hi Rob,
>>>> Rob Weir schrieb:
>>>>> You can see our current Bugzilla taxonomy here:
>>>>> We have around 50 top-level "products" and within that each product
>>>>> has one or more "components".
>>>>> Users, as well as new-volunteers, are confused by the 50 products.
>>>>> For example, it is not at all clear to them where cross-cutting
>>>>> concerns go, e.g., crashes that occur across applications, like the
>>>>> profile corruption issue.
>>>>> Also, some of the "products" are not really dealing with the code of
>>>>> the product, but are project related areas like "qa", "www",
>>>>> "user-faq" or "education".
>>>>> Bugzilla has an option that we can enable that would add an additional
>>>>> level to the hierarchy, called "categories".  A category contains
>>>>> products, which contain components.
>>>>> Is there any interest in having categories enabled?
>>>> No, I would like to go another way and reduce the "product"-list. For
>>>> example, "SDK" has about 500 issues at all from the beginning from today
>>>> about 128000. Compare it to "Word Processor" with about 770 issues in the
>>>> last year. "Products" with low use does not need a division in components.
>>>> There are more such low used "products". I would put them together in two
>>>> "products": "other source code issues" and "other non-source code issues"
>>>> and use their former product name as component.
>>>> The other problem is, that some "products" are only understandable for
>>>> insiders. Or do you know immediately what product "oi" or "ucb" is?
>>> I have no idea.  So if we had categories, these might be put under an
>>> "internals" category.
>>>> So keep only those products, which have got enough issues in the last two
>>>> years to make a "component" list meaningful and which are understandable
>>>> end users.
>>> That's one approach, and it would be OK if the only audience for
>>> Bugzilla was end-users.  But if developers want the finer-grained
>>> products at a code module level, then we can support that as well.
>>> So imagine top-level categories like:
>>> 1) OpenOffice Applications
>>> 2) Internal Modules
>>> 3) Cross-cutting Concerns (performance, accessibility, localization)
>>> 4) Project Infrastructure
>>> Then, to the end user, I hope it would be clear that they go
>>> immediately to "OpenOffice Applications".  In fact, where we give BZ
>>> links for end-users, we can point them directly there.
>>> Something like this could be done quickly, 30 minutes.  We might be
>>> able to do simplification at the product level, as you suggest.  But
>>> that is far more work, and I think having 20 top-level categories
>>> rather than 50 is still too many.  Ideally I think we want 5-7
>>> top-level choices.
>> I agree with having a limited number of top choices. I think that the component level
should be limited to a similar number and ought to default to something like "unknown".
>> If you make massive internal changes for this. It is my hope that you will turn off
email notifications during that short interval.
> I have no desire to make massive internal changes.  I'm volunteering
> to hide the ugliness behind top-level categories, something that I
> could do in 10 minutes with no notification emails, and which will
> immediately make things easier for end-users.
> But if someone is interested in doing the massive cleanup, then they
> are welcome to do that.  But I haven't heard anyone volunteer to do
> that.
> So giving objections to a proposal that a volunteer has actually made,
> the net result is we're deciding to remain with crap.

I was NOT objecting, but since you have difficulty parsing my words I'll try again.

(1) I AGREE with your idea. +1. The question is which components go to which categories, but
I'm sure your initial choices will be almost completely correct and minor changes can be addressed
in the future.

(2) I was suggesting that the next level could use some work.  Even if the component level
gets minimal attention by your change. We should at a minimum think about the component default
for each category so that the user is not required to make a change if they don't understand
the options.

(3) You missed the "IF". I was expressing concern about getting thousands of emails since
that happened in the past. I am glad that this will not be the case. Thank you for that.

Shall I give you an extra +1? Done.


> Regards,
> -Rob
>> Regards,
>> Dave
>>> -Rob
>>>> Kind regards
>>>> Regina

View raw message