On Tue, Feb 5, 2013 at 6:41 PM, Dave Fisher <dave2w...@comcast.net> wrote: > > 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. >
I can toss the existing "products" onto the wiki and propose some categorization. I can probably figure out 75% or so of them, but some are mysteries where I'll need expert opinions. > (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. > This may be why I had difficulties getting your meaning. The next level under a 'category' is a 'product' and under a product is a 'component'. > (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. > The previous email floods were because I was changing the product assignments on the individual issues, doing bulk changes. I'm hoping to avoid doing that again, except where needed selectively. Regards, -Rob > Shall I give you an extra +1? Done. > Thanks, I guess I owe you one then ;-) > Regards, > Dave > >> >> Regards, >> >> -Rob >> >>> Regards, >>> Dave >>> >>>> >>>> -Rob >>>> >>>>> Kind regards >>>>> Regina >>> >
