On Feb 5, 2013, at 3:23 PM, Rob Weir wrote: > 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.
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, Dave > > Regards, > > -Rob > >> Regards, >> Dave >> >>> >>> -Rob >>> >>>> Kind regards >>>> Regina >>
