Calendar Talk:Bugzilla Components

---

Ideas for improving Calendar-Project Bugzilla

Reporting version numbers

The calendar guided bug page could include the version number dropdown.

Reporters are more likely to enter the version number if there is a field on the bugzilla-helper page, rather than filling it in after the first report is submitted.

The build identifier should not be filled in automatically with the browser build identifier

Was mostly useful for calendar extension on mozilla suite. Now that sunbird standalone or lightning extension to thunderbird are primary deployments, the browser version is irrelevant, and filling the field may discourage users from noticing the empty field and filling it with the more relevant build id.

Add a "report bug" command/link that autofills build id and version number

Add a "report bug" command/link to about-page of non-final versions of non-browser products like sunbird and lightning, and it automatically supplies the build-id and version number as part of the URL so it can be included on the enter_bug.cgi?format=guided page.
Requires changes to the bugzilla page to populate the field with the supplied build-id.

Goals for Calendar-Project Bugzilla categories and their names

Why categories?

Separate ownership: category owners receive less bug mail

One reason to have categories is to reduce the bug mail received by the owner of each category. Delegating ownership for a component is one reason to create a separate category for it.

Separate parallel components: contributors can filter unrelated bugs

A second reason to have categories is so bugs with similar descriptions can be differentiated. 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. Similarly, lightning and sunbird menu bugs may be in separate categories.

Separate contributor skills: contributors can filter bugs outside their expertise

A third 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.)

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 user can easily find and choose the correct one rather than stopping at a related category that seems close enough.

Possible Categories

Under construction.

COMPONENT	DESCRIPTION
Calendar management	For issues with calendar creation or managing the list of calendars.
Date/Time/Timezone Pickers	For issues with widgets for choosing a date, time, and/or timezone. Includes minimonth.
Day/Week/Month/Multiweek Views	For issues with grid views. Includes in-line editing events and tasks.
Event/Task Dialog	For issues with the event/task dialog for creating and editing an event or task.
Event/Task List Views	For issues with event/task lists, including searching, filtering, and sorting results.
General: Lightning	For any Lightning issues not covered by another category: menus, toolbars, installation, etc. (Bugs in localization, such as untranslated or mistranslated phrases, should be reported under the Localizations product.)
General: Sunbird	For any Sunbird issues not covered by another category: menus, toolbars, installation, etc. (Bugs in localization, such as untranslated or mistranslated phrases, should be reported under the Localizations product.)
Import/Export+	For issues with format conversions (for importing and exporting, emailing and printing, and cutting, pasting, dragging and dropping to/from another application).
internal core components	For issues with internal core components: calDateTime, calEvent, etc.
libical	For issues with the ical library from Software Studio (implementation of RFC2445 iCalendar).
Preference Options	For issues with preference options.
providers: CalDAV	For issues regarding communications with CalDAV servers.
providers: Local Storage	For issues regarding local calendar storage, based on mozStorage (sqlite).
providers: WebDAV / ICS	For issues regarding communicating .ics files via remote (http:) and local (file:) URIs.
Reminder Alarms	For issues with alarms for scheduled events and tasks.
Security	Application level security issues. If the problem relates to underlying components (PSM, NSS, Core, Toolkit) then please file it in the appropriate product instead of here.
Theme/Skin	For issues with appearance/style: icons, colors, borders, spacing (CSS).
Web pages/documentation	For issues with the Calendar Project web pages (HTML). (Bugs in the on-line help documentation should be reported at the calendarhelp project.)

Category renaming rationales

Renaming 'base' to 'internal core'

'Components in /calendar/base' is not a coherent category from either users' or developers' viewpoints. It holds code that was created with the idea of it being shared someday --- but for a user that has used only one product and not the other, there is no way to know what is shared, let alone what could be shared someday. /calendar/base also contains code from several different developers (core objects, gui views and dialogs), so it might not make sense to make one developer default owner for all of /calendar/base.

Renaming 'Preference dialog' to 'Preference Options'

Under windows, it is called the 'Options' dialog, not 'Preferences'.

categories for internals start with lowercase

Appears less friendly, so non-developers are less likely to choose it: 'internal core', 'libical'.

Renaming 'help documentation' to 'web pages/documentation'

Currently on-line help is managed as a separate project, so rename category to reflect what it does contain, provide a link to the calendarhelp project.

Bugs with these categories

Too early? Sunbird and Lightning don't yet share...

calendar management, day/week/multiweek/month views, event/task dialog, event/task list, themes, ...
Q. is there enough separate work to keep their categories separate?
Q. Are the lightning and sunbird GUI teams going to continue to be separate?

Too many?

Explicitly naming the major parts of the GUI makes it clear where to report bugs in them. On the other hand, making the list longer can make it harder for users to spot the best category, particularly because in bugzilla-helper the list must be scrolled.

---