Calendar:Bugzilla Components:Goals

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.