101
edits
Calendar:Bugzilla Components:Goals: Difference between revisions
Jump to navigation
Jump to search
Calendar:Bugzilla Components:Goals (view source)
Revision as of 13:04, 1 October 2005
, 1 October 2005(wikify headings, add "who uses categories?")
m ((moved from http://wiki.mozilla.org/index.php?title=Calendar_Talk:Bugzilla_Components)) |
((wikify headings, add "who uses categories?")) |
||
| 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>Separate | <dt id="separate-parallel-components">Separate parallel components: | ||
<dd>One reason to have categories | reporters, triagers, and developers | ||
can filter unrelated bugs</dt> | |||
<dd>One reason to have categories is so bugs with similar descriptions | |||
can 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. | |||
</dd> | </dd> | ||
<dt>Separate | <dt id="separate-skills">Separate contributor skills: | ||
<dd> | contributors can filter bugs outside their expertise</dt> | ||
<dd>Another reason to have separate categories is to 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.) | |||
</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 64: | ||
</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">Developing</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> | ||