On Tue, Feb 5, 2013 at 6:06 PM, Dave Fisher <dave2w...@comcast.net> wrote: > > 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. >
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. Regards, -Rob > Regards, > Dave > >> >> -Rob >> >>> Kind regards >>> Regina >
