On Feb 5, 2013, at 1:43 PM, Rob Weir wrote: > On Tue, Feb 5, 2013 at 4:22 PM, Regina Henschel <rb.hensc...@t-online.de> > wrote: >> Hi Rob, >> Rob Weir schrieb: >> >>> You can see our current Bugzilla taxonomy here: >>> >>> https://issues.apache.org/ooo/describecomponents.cgi >>> >>> 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 to >> 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. Regards, Dave > > -Rob > >> Kind regards >> Regina
