Calendar Talk:Bugzilla Components: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (fix bugzilla links)
((moved content to separate pages, replaced with issues/questions))
Line 1: Line 1:
<hr>
===Process issues===
<h1>Ideas for improving Calendar-Project Bugzilla</h1>


<h2>Reporting version numbers</h2>
Q. What happens to bugs in deleted categories?
<dl>
* Are those bugs deleted?
<dt>The [https://bugzilla.mozilla.org/enter_bug.cgi?product=Calendar&format=guided calendar guided bug page] could include the version number dropdown.</dt>
* Are those bugs moved to another category, say General?
<dd>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.
</dd>


<dt>The build identifier should not be filled in automatically
Q. What happens to bugs that belong in a created category?
with the browser build identifier</dt>
* Are new categories empty? (ok for new components, not for reorg.)
<dd>Was mostly useful for calendar extension on mozilla suite.
* Will old bugs and enhancement requests be migrated into new categories immediately, or over time?
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. (Filed [https://bugzilla.mozilla.org/show_bug.cgi?id=308943 bug 308943] [[User:Gekacheka|Gekacheka]] 07:59, 17 Sep 2005 (PDT))
</dd>


<dt>Add a "report bug" command/link that autofills
build id and version number</dt>
<dd>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. <br>Requires changes to the bugzilla page to populate the field with the
supplied build-id. (Filed [https://bugzilla.mozilla.org/show_bug.cgi?id=308950 bug 308950] [[User:Gekacheka|Gekacheka]] 07:59, 17 Sep 2005 (PDT))
</dd>


</dl>
===Goal Issues===


<h2>Goals for Calendar-Project Bugzilla categories and their names</h2>
Q. What are reasons for making change now?
* Provider: WebDav/ICS bugs don't fit into other categories.
* Why preference/options category now?
* Why day/week/multiweek/month view category now?


<h3>Why categories?</h3>
Q. What are goals for eventual categories?
* A set of proposed goals: [[Calendar:Bugzilla_Components:Goals]]
* A set of proposed eventual categories to meet these goals: [[Calendar:Bugzilla_Components:Proposal_By_Function]]


<dl>


<dt>Separate ownership: category owners receive less bug mail</dt>
===Particular component issues===
<dd>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.
</dd>


<dt>Separate parallel components: contributors can filter unrelated bugs</dt>
Q. It's not clear what goes in 'base'? Should all UI be removed from it?
<dd>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.
</dd>


<dt>Separate contributor skills: contributors can filter bugs outside
Q. Why do some UI parts/functions have separate category, while others do not?
their expertise</dt>
* current proposal has separate category for preferences, and for day/week/multiweek/month view,  
<dd>A third reason to have
* but not say for list/search/filter views, date pickers, event/task dialog, nor for import/export, alarms, printing, ...
separate categories is to make it easier for contributors to find bugs
* at what time would it be appropriate to eventually add these categories?
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>
</dl>


<h3>What makes good names?</h3>
Q. Is it ok to rename "Help Documentation" to "Web pages/documentation"?
 
* The category holds bugs about the web site, not the calendar online help, which is managed separately at the [http://calendarhelp.mozdev.org/bugs.html calendarhelp] project.
<dl>
<dt>Reporters understand categories</dt>
<dd>When a user reports a bug, which category fits the bug should
be clear to the user reporting the bug.
<br>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.
<br>For the this goal it would be nice to have categories based on
end-user functionality, such as Display, Reminders, Networking,
Import/Export.
<br>(Negative example: categories based on what directory holds the
implementation of a feature, which a user has no way to know.)
</dd>
 
<dt>Reporters find best category</dt>
<dd>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.
</dd>
 
</dl>
 
<H2>Possible Categories</h2>
 
Under construction.
 
<table frame="border" rules="rows" style="border-color: silver">
<tr><th>COMPONENT                      <th>DESCRIPTION
<tr><td>Calendar management            <td>For issues with calendar creation or managing the list of calendars.
<tr><td>Date/Time/Timezone Pickers      <td>For issues with widgets for choosing a date, time, and/or timezone.  Includes minimonth.
<tr><td>Day/Week/Month/Multiweek Views  <td>For issues with grid views. Includes in-line editing events and tasks.
<tr><td>Event/Task Dialog              <td>For issues with the event/task dialog for creating and editing an event or task.
<tr><td>Event/Task List Views          <td>For issues with event/task lists, including searching, filtering, and sorting results.
<tr><td>General: Lightning              <td>For any Lightning issues not covered by another category: menus, toolbars, installation, etc. <br>(Bugs in localization, such as untranslated or mistranslated phrases, should be reported under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Mozilla%20Localizations Localizations] product.)
<tr><td>General: Sunbird                <td>For any Sunbird issues not covered by another category: menus, toolbars, installation, etc. <br>(Bugs in localization, such as untranslated or mistranslated phrases, should be reported under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Mozilla%20Localizations Localizations] product.)
<tr><td>Import/Export+ <td>For issues with format conversions (for importing and exporting, emailing and printing, and cutting, pasting, dragging and dropping to/from another application).
<tr><td>internal core components        <td>For issues with internal core components: calDateTime, calEvent, etc.
<tr><td>libical         <td>For issues with the [http://www.softwarestudio.org/libical/ ical library] from Software Studio (implementation of [http://ietfreport.isoc.org/idref/rfc2445/ RFC2445 iCalendar]).
<tr><td>Preference Options              <td>For issues with preference options.
<tr><td>providers: CalDAV              <td>For issues regarding communications with CalDAV servers.
<tr><td>providers: Local Storage        <td>For issues regarding local calendar storage, based on mozStorage (sqlite).
<tr><td>providers: WebDAV / ICS        <td>For issues regarding communicating .ics files via remote (http:) and local (file:) URIs.
<tr><td>Reminder Alarms                <td>For issues with alarms for scheduled events and tasks.
<tr><td>Security                        <td>Application level security issues. <br>If the problem relates to underlying components (PSM, NSS, Core, Toolkit) then please file it in the appropriate product instead of here.
<tr><td>Theme/Skin                      <td>For issues with appearance/style: icons, colors, borders, spacing (CSS).
<tr><td>Web pages/documentation        <td>For issues with the Calendar Project web pages (HTML). <br>(Bugs in the on-line help documentation should be reported at the [http://calendarhelp.mozdev.org/bugs.html calendarhelp] project.)
</table>
 
<h3>Category renaming rationales</h3>
 
<dl>
 
<dt>Renaming 'base' to 'internal core'</dt>
<dd>
'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.
</dd>
 
<dt>Renaming 'Preference dialog' to 'Preference Options'</dt>
<dd>Under windows, it is called the 'Options' dialog, not 'Preferences'.
</dd>
 
<dt>categories for internals start with lowercase<dt>
<dd>Appears less friendly, so non-developers are less likely to choose it:
'internal core', 'libical'.
</dd>
 
<dt>Renaming 'help documentation' to 'web pages/documentation'</dt>
<dd>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. 
</dd>
 
</dl>
 
<h3>Bugs with these categories</h3>
 
<dl>
 
<dt>Too early?  Sunbird and Lightning don't yet share...</dt>
<dd>calendar management, day/week/multiweek/month views,
event/task dialog, event/task list, themes, ...
<br>Q. is there enough separate work to keep their categories separate?
<br>Q. Are the lightning and sunbird GUI teams going to continue to be
separate?
</dd>
 
<dt>Too many?</dt>
<dd>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.
</dd>
 
</dl>
 
<hr>

Revision as of 13:01, 1 October 2005

Process issues

Q. What happens to bugs in deleted categories?

  • Are those bugs deleted?
  • Are those bugs moved to another category, say General?

Q. What happens to bugs that belong in a created category?

  • Are new categories empty? (ok for new components, not for reorg.)
  • Will old bugs and enhancement requests be migrated into new categories immediately, or over time?


Goal Issues

Q. What are reasons for making change now?

  • Provider: WebDav/ICS bugs don't fit into other categories.
  • Why preference/options category now?
  • Why day/week/multiweek/month view category now?

Q. What are goals for eventual categories?


Particular component issues

Q. It's not clear what goes in 'base'? Should all UI be removed from it?

Q. Why do some UI parts/functions have separate category, while others do not?

  • current proposal has separate category for preferences, and for day/week/multiweek/month view,
  • but not say for list/search/filter views, date pickers, event/task dialog, nor for import/export, alarms, printing, ...
  • at what time would it be appropriate to eventually add these categories?

Q. Is it ok to rename "Help Documentation" to "Web pages/documentation"?

  • The category holds bugs about the web site, not the calendar online help, which is managed separately at the calendarhelp project.
Retrieved from "https://wiki.mozilla.org/index.php?title=Calendar_Talk:Bugzilla_Components&oldid=12372"