Calendar Talk:Bugzilla Components: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Ideas for improving Calendar-Project Bugzilla)
 
m (fix link to 0.3a2 task list)
 
(8 intermediate revisions by 3 users not shown)
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.
</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.
</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>
=== Comments from mvl ===
My comments: The less components, the better. More components will only create confusion, bugs moved between components, bugspam, useless comments etc.
I will see all bugs anyway. We don't have tons of very specialized developers, the devs we have will have to look at everything anyway.


<dt>Separate ownership: category owners receive less bug mail</dt>
<blockquote><em>(This points out categories are not just for separation, but also for gathering bugs that might otherwise be filed under different terms.  Added goal [http://wiki.mozilla.org/Calendar:Bugzilla_Components:Goals#establish-component-names establish component names]. [[User:Gekacheka|Gekacheka]] 20:59, 6 Oct 2005 (PDT))</em></blockquote>
<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>
<blockquote><em>(MVL's comment seems to argue for just one component, 'General'.  I think we should try to make the calendar bugzilla database more accessible to potential reporters, triagers, and patch contributors who don't see every bug, and therefore can use some help providing the right names when searching for duplicates, or relating the bug database to a component-name based roadmap such as [[Calendar:0.3a2_Task_List]].  Changes in component will likely be in conjunction with confirming the bug or changing the summary, so it probably won't add significantly to the bugzilla mail.  When reporters choose from a list of component names, they may be less likely to use a synonym, so the component name won't need to be added to the summary as often. [[User:Gekacheka|Gekacheka]] 06:53, 12 Nov 2005 (PST))</em></blockquote>
<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
==Proposal 1 Issues==
their expertise</dt>
<dd>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.)
</dd>
</dl>


<h3>What makes good names?</h3>
Q. It's not clear what goes in 'base'?  Should all UI be removed from it?


<dl>
Q. Why do some UI parts/functions have separate category, while others do not?
<dt>Reporters understand categories</dt>
* current proposal has separate category for preferences, and for day/week/multiweek/month view,
<dd>When a user reports a bug, which category fits the bug should
* but not say for list/search/filter views, date pickers, event/task dialog, nor for import/export, alarms, printing, ...
be clear to the user reporting the bug.
* under what condition would it be appropriate to eventually add these categories?
<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>
==Proposal 2 Issues==


<H2>Possible Categories</h2>
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.


Under construction.
==Proposal 3 Issues==


<table frame="border" rules="rows" style="border-color: silver">
Q. why do 3 of the providers get their own bugzilla component? What about bugs in the remaining providers? 
<tr><th>COMPONENT                      <th>DESCRIPTION
* Should all 5 providers get their own bugzilla component?
<tr><td>Calendar management            <td>For issues with calendar creation or managing the list of calendars.
* Should all 5 providers be one bugzilla component? ([[User:Gekacheka|Gekacheka]] 06:53, 12 Nov 2005 (PST))
<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>

Latest revision as of 00:31, 19 April 2006

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?

Comments from mvl

My comments: The less components, the better. More components will only create confusion, bugs moved between components, bugspam, useless comments etc. I will see all bugs anyway. We don't have tons of very specialized developers, the devs we have will have to look at everything anyway.

(This points out categories are not just for separation, but also for gathering bugs that might otherwise be filed under different terms. Added goal establish component names. Gekacheka 20:59, 6 Oct 2005 (PDT))

(MVL's comment seems to argue for just one component, 'General'. I think we should try to make the calendar bugzilla database more accessible to potential reporters, triagers, and patch contributors who don't see every bug, and therefore can use some help providing the right names when searching for duplicates, or relating the bug database to a component-name based roadmap such as Calendar:0.3a2_Task_List. Changes in component will likely be in conjunction with confirming the bug or changing the summary, so it probably won't add significantly to the bugzilla mail. When reporters choose from a list of component names, they may be less likely to use a synonym, so the component name won't need to be added to the summary as often. Gekacheka 06:53, 12 Nov 2005 (PST))

Proposal 1 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, ...
  • under what condition would it be appropriate to eventually add these categories?


Proposal 2 Issues

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.

Proposal 3 Issues

Q. why do 3 of the providers get their own bugzilla component? What about bugs in the remaining providers?

  • Should all 5 providers get their own bugzilla component?
  • Should all 5 providers be one bugzilla component? (Gekacheka 06:53, 12 Nov 2005 (PST))
Retrieved from "https://wiki.mozilla.org/index.php?title=Calendar_Talk:Bugzilla_Components&oldid=24214"