Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Received-SPF: pass (athena.apache.org: domain of dave2wave@comcast.net
 designates 76.96.27.243 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
Subject: Re: Bugzilla -- Any interest in enabling "categories"?
From: Dave Fisher <dave2wave@comcast.net>
In-Reply-To: 
 <CAP-ksogo1PKmeDz5z9nFhKrjhoSczRS6RgKcsdp08gVFeB=9og@mail.gmail.com>
Date: Tue, 5 Feb 2013 15:41:43 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <16AD0D2E-6AFB-451A-B5BC-1F349090B91A@comcast.net>
References: 
 <CAP-ksojeWVobn1T+6-EA5m=DxhmvkYwMc4Cg_xuRDz3J1LkfCA@mail.gmail.com>
 <511177F9.5070004@t-online.de>
 <CAP-ksohrj6f+rAQfd-gNvbm9JahUQpixGS1A18dFEY_eOCTUJg@mail.gmail.com>
 <E1426E47-AB49-42D3-827E-E7E33E047A96@comcast.net>
 <CAP-ksogo1PKmeDz5z9nFhKrjhoSczRS6RgKcsdp08gVFeB=9og@mail.gmail.com>
To: dev@openoffice.apache.org


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

> On Tue, Feb 5, 2013 at 6:06 PM, Dave Fisher <dave2wave@comcast.net> =
wrote:
>>=20
>> On Feb 5, 2013, at 1:43 PM, Rob Weir wrote:
>>=20
>>> On Tue, Feb 5, 2013 at 4:22 PM, Regina Henschel =
<rb.henschel@t-online.de> wrote:
>>>> Hi Rob,
>>>> Rob Weir schrieb:
>>>>=20
>>>>> You can see our current Bugzilla taxonomy here:
>>>>>=20
>>>>> https://issues.apache.org/ooo/describecomponents.cgi
>>>>>=20
>>>>> We have around 50 top-level "products" and within that each =
product
>>>>> has one or more "components".
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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".
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Is there any interest in having categories enabled?
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> The other problem is, that some "products" are only understandable =
for
>>>> insiders. Or do you know immediately what product "oi" or "ucb" is?
>>>>=20
>>>=20
>>> I have no idea.  So if we had categories, these might be put under =
an
>>> "internals" category.
>>>=20
>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> 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.
>>>=20
>>> So imagine top-level categories like:
>>>=20
>>> 1) OpenOffice Applications
>>>=20
>>> 2) Internal Modules
>>>=20
>>> 3) Cross-cutting Concerns (performance, accessibility, localization)
>>>=20
>>> 4) Project Infrastructure
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> 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".
>>=20
>> If you make massive internal changes for this. It is my hope that you =
will turn off email notifications during that short interval.
>>=20
>=20
> 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.
>=20
> 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.
>=20
> 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

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