Calendar Talk:Bugzilla Components: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
m (fix link to 0.3a2 task list)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
===Process issues===
==Process Issues==


Q. What happens to bugs in deleted categories?
Q. What happens to bugs in deleted categories?
Line 10: Line 10:




===Goal Issues===
==Goal Issues==


Q. What are reasons for making change now?
Q. What are reasons for making change now?
Line 21: Line 21:
* A set of proposed eventual categories to meet these goals: [[Calendar:Bugzilla_Components:Proposal_By_Function]]
* A set of proposed eventual categories to meet these goals: [[Calendar:Bugzilla_Components:Proposal_By_Function]]


=== 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.
<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>
<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>


===Particular component issues===
==Proposal 1 Issues==


Q. It's not clear what goes in 'base'?  Should all UI be removed from it?
Q. It's not clear what goes in 'base'?  Should all UI be removed from it?
Line 29: Line 36:
* current proposal has separate category for preferences, and for day/week/multiweek/month view,  
* 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, ...
* 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?
* 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"?
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.
* 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.


==Proposal 3 Issues==


== Comments from mvl ==
Q. why do 3 of the providers get their own bugzilla component?  What about bugs in the remaining providers? 
My comments: The less components, the better. More components will only create confusion, bugs moved between components, bugspam, useless comments etc.
* Should all 5 providers get their own bugzilla component? 
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.
* Should all 5 providers be one bugzilla component?  ([[User:Gekacheka|Gekacheka]] 06:53, 12 Nov 2005 (PST))

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))