You are viewing a plain text version of this content. The canonical link for it is here.
Posted to qa@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2013/02/05 19:27:11 UTC
Bugzilla -- Any interest in enabling "categories"?
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?
Advantage:
-- Can have a cleaner, easier-to-use taxonomy. We could clearly
separate product-related from project-related products. We could make
it easier for users to find the application-level category and enter
their bugs there.
-- Easier to generate reports and statistics on QA status. Typically
we want to know how many new/open/critical bugs exist for the product,
not for the website or other non-product areas.
Disadvantage:
An additional mouse click when entering new bugs, though it might
actually be faster since user would not need to search through a list
of 50 products to find the one they want.
Regards,
-Rob
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Feb 5, 2013 at 10:27 AM, Rob Weir <ro...@apache.org> wrote:
> 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?
>
OK...I am confused here. When I log in to BZ right now, and click "File a
Bug" I am automatically shown this list, so it appears they are already
enabled, and I must chose a category. And then, there's components inside
of the categories.
At any rate...it would better I think to reduce/combine categories in some
way though it would take some time to figure out what/how to combine
without losing existing information.
But personally, I've wondered about this list for a while. I'm sure
end-users have problems with it though.
>
> Advantage:
>
> -- Can have a cleaner, easier-to-use taxonomy. We could clearly
> separate product-related from project-related products. We could make
> it easier for users to find the application-level category and enter
> their bugs there.
>
> -- Easier to generate reports and statistics on QA status. Typically
> we want to know how many new/open/critical bugs exist for the product,
> not for the website or other non-product areas.
>
> Disadvantage:
>
> An additional mouse click when entering new bugs, though it might
> actually be faster since user would not need to search through a list
> of 50 products to find the one they want.
>
> Regards,
>
> -Rob
>
--
----------------------------------------------------------------------------------------
MzK
"A great deal of talent is lost to the world
for want of a little courage."
-- Sydney Smith
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Feb 5, 2013 at 6:41 PM, Dave Fisher <da...@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 <da...@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...@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
>>>
>
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Dave Fisher <da...@comcast.net>.
On Feb 5, 2013, at 3:23 PM, Rob Weir wrote:
> On Tue, Feb 5, 2013 at 6:06 PM, Dave Fisher <da...@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...@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
>>
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Feb 5, 2013 at 6:06 PM, Dave Fisher <da...@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...@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
>
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Dave Fisher <da...@comcast.net>.
On Feb 5, 2013, at 1:43 PM, Rob Weir wrote:
> On Tue, Feb 5, 2013 at 4:22 PM, Regina Henschel <rb...@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
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Feb 5, 2013 at 4:22 PM, Regina Henschel <rb...@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.
-Rob
> Kind regards
> Regina
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 02/05/2013 10:28 PM, schrieb janI:
> On 5 February 2013 22:22, Regina Henschel<rb...@t-online.de> wrote:
>
>> Hi Rob,
>> Rob Weir schrieb:
>>
>> You can see our current Bugzilla taxonomy here:
>>>
>>> https://issues.apache.org/ooo/**describecomponents.cgi<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?
>>
>> 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.
>>
> +1 for simplification, and also name it with "external" names that users
> understand like draw, write etc.
Also my +1 for Regina's suggestion to delete old and no longer needed
stuff - to make it easier for all.
Marcus
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by janI <ja...@apache.org>.
On 5 February 2013 22:22, Regina Henschel <rb...@t-online.de> wrote:
> Hi Rob,
> Rob Weir schrieb:
>
> You can see our current Bugzilla taxonomy here:
>>
>> https://issues.apache.org/ooo/**describecomponents.cgi<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?
>
> 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.
>
+1 for simplification, and also name it with "external" names that users
understand like draw, write etc.
jan I.
>
> Kind regards
> Regina
>
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Regina Henschel <rb...@t-online.de>.
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?
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.
Kind regards
Regina
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Andrea Pescetti <pe...@apache.org>.
On 08/02/2013 Rob Weir wrote:
> So with a new top-level category, I can easily get to 3 or 4 top level
> items, and then under applications reduce it to the core set of 5
> products. Can we get anywhere close by combining products?
I had a look again. If the aim is to avoid presenting lists of more than
10 items, there is no way to do it by moving products.
With categories, we should have a category for application-specific bugs
(with the 6 components only but let's please improve their description
so that it includes the application name!), a category for
cross-application bugs ("framework", "chart", "formula", "scripting",
"vba", "bibliographic", "gsl", "ui"...) and other categories for
websites and so on.
If you manage to find a proposal for a taxonomy that is clear for new
bug reporters and efficient for experienced QA people too it would
surely be nice. But I think we'll have to see the proposed taxonomy tree
on this list, since I cannot find something really clear (for example,
my proposal above would have the problem that a bug with charts in Calc
should be reported in "generic"-"chart" rather than
"application"-"calc", but people would use the latter; and ultimately
this is probably not going to hurt QA or development too much!).
Regards,
Andrea.
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Rob Weir <ro...@apache.org>.
On Fri, Feb 8, 2013 at 2:29 AM, Andrea Pescetti <pe...@apache.org> wrote:
> On 05/02/2013 Rob Weir wrote:
>>
>> 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". ...
>>
>> Bugzilla has an option that we can enable that would add an additional
>> level to the hierarchy, called "categories".
>
>
> I wouldn't add a new level of hierarchy to a system that is already quite
> complex. But some of the existing products could become components of the
> existing "obsolete" product (groupware, oopm, wp, user-faq,
> special_projects, kde, printing, testextension, stats...) and the
> description of the core applications could be improved by adding their name:
> for example,
> ---
> word processor: This is the word processor and HTML editor application.
> ---
> should include "Writer" somewhere.
>
If you think we can get down to a small number of top-level products
this way, then this is fine. But going from 50 to 40 or even 50 to 30
won't really improve things. We really want something under 10:
http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
Note: what experienced BZ issues feel on this question, and how new
users experience it, will be entirely different. New users don't have
the taxonomy memorized. They don't know what they are looking for
exactly. So scanning a list of 30 items is a problem for them.
So with a new top-level category, I can easily get to 3 or 4 top level
items, and then under applications reduce it to the core set of 5
products. Can we get anywhere close by combining products/
-Rob
> Regards,
> Andrea.
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Andrea Pescetti <pe...@apache.org>.
On 05/02/2013 Rob Weir wrote:
> 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". ...
> Bugzilla has an option that we can enable that would add an additional
> level to the hierarchy, called "categories".
I wouldn't add a new level of hierarchy to a system that is already
quite complex. But some of the existing products could become components
of the existing "obsolete" product (groupware, oopm, wp, user-faq,
special_projects, kde, printing, testextension, stats...) and the
description of the core applications could be improved by adding their
name: for example,
---
word processor: This is the word processor and HTML editor application.
---
should include "Writer" somewhere.
Regards,
Andrea.
Re: Bugzilla -- Any interest in enabling "categories"?
Posted by Andrea Pescetti <pe...@apache.org>.
On 05/02/2013 Rob Weir wrote:
> 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". ...
> Bugzilla has an option that we can enable that would add an additional
> level to the hierarchy, called "categories".
I wouldn't add a new level of hierarchy to a system that is already
quite complex. But some of the existing products could become components
of the existing "obsolete" product (groupware, oopm, wp, user-faq,
special_projects, kde, printing, testextension, stats...) and the
description of the core applications could be improved by adding their
name: for example,
---
word processor: This is the word processor and HTML editor application.
---
should include "Writer" somewhere.
Regards,
Andrea.