Calendar:Bugzilla Components:Goals: Difference between revisions
Jump to navigation
Jump to search
m ((moved from http://wiki.mozilla.org/index.php?title=Calendar_Talk:Bugzilla_Components)) |
m (fixup headings) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Goals for Calendar-Project Bugzilla categories and their names== | |||
Clear goals can help evaluating proposals. This page | |||
explains some goals uncovered so far. | |||
===Why categories?=== | |||
<dl> | <dl> | ||
<dt> | <dt id="establish-component-names">Establish component names</dt> | ||
<dd> | <dd>Bug searchers and filers can choose from list of component names | ||
rather than guess key words. | |||
Without component categories, component bugs are filed under many | |||
variant names. For example, task list bugs may be titled "task" or | |||
"todo" or "to-do", with "unifinder" or "list" or "table" or "tree". | |||
Reporters guess only one or two of the variations and miss duplicate | |||
bugs. Even experienced developers that know all the variations must | |||
make multiple searches to return all the bugs. | |||
With component categories, the component list gives reporters a menu | |||
of established component names. New bugs will be filed under an | |||
established component name. Searches more reliably return all the | |||
related component bugs, especially for reporters who didn't know the | |||
established name before. (When previous reports are found, new | |||
contributors can spend their time building on knowledge of an existing | |||
bug, rather than filing a report only to be later discouraged to find | |||
that they didn't know enough even to find the previous report, and | |||
wasted their time filing a duplicate.) | |||
</dd> | </dd> | ||
<dt>Separate parallel components | <dt id="separate-parallel-components">Separate parallel components</dt> | ||
<dd> | <dd> | ||
Reporters, triagers, and developers can filter unrelated bugs. | |||
working on, say the ICS calendar provider, a contributor may want to | |||
see other bugs on that component that might be related, and suppress | Categories enable bugs with similar descriptions | ||
bugs on parallel components, such as the local storage provider, that | to be differentiated. For example, while searching for previous bug | ||
might have similar summary descriptions. | reports, reporter or triager may want to list Lightning "menu" bugs | ||
without the Sunbird "menu" bugs. Or while working on, say the ICS | |||
calendar provider, a contributor may want to see other bugs on that | |||
component that might be related, and suppress bugs on parallel | |||
components, such as the local storage provider, that might have | |||
similar summary descriptions. | |||
</dd> | </dd> | ||
<dt>Separate contributor skills | <dt id="separate-skills">Separate contributor skills</dt> | ||
<dd>Contributors can filter out bugs outside their expertise. | |||
<dd> | |||
Categories can make it easier | |||
on which they can contribute. It often makes sense to put components | for contributors to find bugs on which they can contribute. It often | ||
written in different languages (html doc, css themes, JS/xul/xbl, | makes sense to put components written in different languages (html | ||
C++/idl, sql, pl/sh/make,...) in different categories, so contributors can | doc, css themes, JS/xul/xbl, C++/idl, sql, pl/sh/make,...) in | ||
suppress bugs in areas outside their expertise. (However, note that | different categories, so contributors can suppress bugs in areas | ||
some calendar components are implemented partly with several | outside their expertise. (However, note that some calendar components | ||
languages, such as a JS wrapper around a C++/idl core.) | are implemented partly with several languages, such as a JS wrapper | ||
around a C++/idl core.) | |||
</dd> | |||
<dt id="separate-ownership">Separate ownership responsibility</dt> | |||
<dd>New contributors see address of default assignee as someone | |||
to ask for questions, or to ask for review. | |||
<br>Category owners (and managers) can survey bugs in the category | |||
to evaluate needs and progress. | |||
Delegating responsibility for a component is | |||
one reason to create a separate category for it. | |||
<br>Also, separating ownership reduces the bug mail received by the owner | |||
of each category. | |||
</dd> | </dd> | ||
</dl> | </dl> | ||
===What makes good names?=== | |||
<dl> | <dl> | ||
<dt>Reporters understand categories</dt> | <dt id="reporters-understand">Reporters understand categories</dt> | ||
<dd>When a user reports a bug, which category fits the bug should | <dd>When a user reports a bug, which category fits the bug should | ||
be clear to the user reporting the bug. | be clear to the user reporting the bug. | ||
| Line 50: | Line 88: | ||
</dd> | </dd> | ||
<dt>Reporters find best category</dt> | <dt id="reporters-find-best">Reporters find best category</dt> | ||
<dd>Related names can group closely related components | <dd>Related names can group closely related components | ||
such as provider: Local Storage, provider: CalDAV, provider: WebDAV/ICS, | (such as provider: Local Storage, provider: CalDAV, provider: WebDAV/ICS), | ||
so a | so a reporter can easily find and choose the correct one rather than | ||
stopping at a related category that seems close enough. | stopping at a related category that seems close enough. | ||
</dd> | </dd> | ||
</dl> | |||
===Who uses Calendar-Project Bugzilla Categories?=== | |||
The stakeholders who are affected by changes in the categories act in | |||
one or more of the following roles. | |||
<dl> | |||
<dt id="reporters">Reporters</dt> | |||
<dd>Searching for previous bugs on the same topic. | |||
<br>Entering a new bug, or requesting an enhancement, requires a category. | |||
<br>Good categories can help reporters find previous bugs and pick the | |||
right category for new bugs. Frequently a reporter is a user or | |||
tester who is not familiar with the code and may not be a | |||
programmer. Successful reporters may later try to contribute in | |||
other ways. | |||
</dd> | |||
<dt id="triagers">Triagers</dt> | |||
<dd>Searching for previous bugs on the same topic (duplicates). | |||
<br>Recategorizing bugs to specific categories. | |||
<br>Good categories can reduce the load of duplicate or recategorized bugs, | |||
so triagers can focus on clarifying/simplifying reproduceable test | |||
cases. | |||
</dd> | |||
<dt id="developers">Developers</dt> | |||
<dd>Searching for bugs to work on (matching interest and skills). | |||
<br>Searching for bugs related to a part they are working on. | |||
<br>First-time contributors typically "scratch an itch", a bug that | |||
is bothering them as a user, but once they are successful then | |||
may look for similar things they can fix. | |||
</dd> | |||
<dt id="owners">Bugzilla Category Owners</dt> | |||
<dd>Usually manages and approves (reviews) code in category. | |||
<br>Bugzilla sends mail to owner for every change to a bug in category. | |||
<br>May search category to evaluate what bugs should have priority, | |||
what areas need encouragement for the next milestone, etc. | |||
</dd> | |||
<dt id="managers">Managers</dt> | |||
<dd>Managers other than the owner may also use categories to evaluate | |||
progress and workloads, what areas have user interest, what areas | |||
need encouragement for the next milestone, etc., perhaps using | |||
Bugzilla [https://bugzilla.mozilla.org/report.cgi reporting and graphing] | |||
capabilities. | |||
</dl> | </dl> | ||
Latest revision as of 03:52, 7 October 2005
Goals for Calendar-Project Bugzilla categories and their names
Clear goals can help evaluating proposals. This page explains some goals uncovered so far.
Why categories?
- Establish component names
- Bug searchers and filers can choose from list of component names rather than guess key words. Without component categories, component bugs are filed under many variant names. For example, task list bugs may be titled "task" or "todo" or "to-do", with "unifinder" or "list" or "table" or "tree". Reporters guess only one or two of the variations and miss duplicate bugs. Even experienced developers that know all the variations must make multiple searches to return all the bugs. With component categories, the component list gives reporters a menu of established component names. New bugs will be filed under an established component name. Searches more reliably return all the related component bugs, especially for reporters who didn't know the established name before. (When previous reports are found, new contributors can spend their time building on knowledge of an existing bug, rather than filing a report only to be later discouraged to find that they didn't know enough even to find the previous report, and wasted their time filing a duplicate.)
- Separate parallel components
- Reporters, triagers, and developers can filter unrelated bugs. Categories enable bugs with similar descriptions to be differentiated. For example, while searching for previous bug reports, reporter or triager may want to list Lightning "menu" bugs without the Sunbird "menu" bugs. Or while working on, say the ICS calendar provider, a contributor may want to see other bugs on that component that might be related, and suppress bugs on parallel components, such as the local storage provider, that might have similar summary descriptions.
- Separate contributor skills
- Contributors can filter out bugs outside their expertise. Categories can make it easier for contributors to find bugs on which they can contribute. It often makes sense to put components written in different languages (html doc, css themes, JS/xul/xbl, C++/idl, sql, pl/sh/make,...) in different categories, so contributors can suppress bugs in areas outside their expertise. (However, note that some calendar components are implemented partly with several languages, such as a JS wrapper around a C++/idl core.)
- Separate ownership responsibility
- New contributors see address of default assignee as someone
to ask for questions, or to ask for review.
Category owners (and managers) can survey bugs in the category to evaluate needs and progress. Delegating responsibility for a component is one reason to create a separate category for it.
Also, separating ownership reduces the bug mail received by the owner of each category.
What makes good names?
- Reporters understand categories
- When a user reports a bug, which category fits the bug should
be clear to the user reporting the bug.
This reduces work (and bug mail) triaging bugs in the wrong category, and improves the signal to noise ratio when searching for bugs by category.
For the this goal it would be nice to have categories based on end-user functionality, such as Display, Reminders, Networking, Import/Export.
(Negative example: categories based on what directory holds the implementation of a feature, which a user has no way to know.) - Reporters find best category
- Related names can group closely related components (such as provider: Local Storage, provider: CalDAV, provider: WebDAV/ICS), so a reporter can easily find and choose the correct one rather than stopping at a related category that seems close enough.
Who uses Calendar-Project Bugzilla Categories?
The stakeholders who are affected by changes in the categories act in one or more of the following roles.
- Reporters
- Searching for previous bugs on the same topic.
Entering a new bug, or requesting an enhancement, requires a category.
Good categories can help reporters find previous bugs and pick the right category for new bugs. Frequently a reporter is a user or tester who is not familiar with the code and may not be a programmer. Successful reporters may later try to contribute in other ways. - Triagers
- Searching for previous bugs on the same topic (duplicates).
Recategorizing bugs to specific categories.
Good categories can reduce the load of duplicate or recategorized bugs, so triagers can focus on clarifying/simplifying reproduceable test cases. - Developers
- Searching for bugs to work on (matching interest and skills).
Searching for bugs related to a part they are working on.
First-time contributors typically "scratch an itch", a bug that is bothering them as a user, but once they are successful then may look for similar things they can fix. - Bugzilla Category Owners
- Usually manages and approves (reviews) code in category.
Bugzilla sends mail to owner for every change to a bug in category.
May search category to evaluate what bugs should have priority, what areas need encouragement for the next milestone, etc. - Managers
- Managers other than the owner may also use categories to evaluate progress and workloads, what areas have user interest, what areas need encouragement for the next milestone, etc., perhaps using Bugzilla reporting and graphing capabilities.