Changes between Version 12 and Version 13 of SubTickets

Timestamp:

Jan 17, 2015, 4:54:10 PM (9 years ago)

Author:

figaro

Comment:

Cosmetic changes

SubTickets

@@ -1 @@
-== Subtickets Specification Proposal ==
+= Proposal for Subtickets specifications
 
-Here is a proposal for the specifications of Trac Subtickets. See related tickets #31, #886, #2344, #3003, #6328 and #7422. I have not discussed viewing ticket hierarchies because I think this can be a feature added after these are completed. Moreover, I think that we should minimise the impact of these changes so that most users will hardly notice the feature was added (in case they don't want it). Therefore, parent and child tickets should be treated exactly the same as tickets are now, with the few simple and basic modifications described below.
+Here is a proposal for the specifications of Trac Subtickets. See related tickets #31, #886, #2344, #3003, #6328 and #7422. I have not discussed viewing ticket hierarchies because I think this can be a feature added after these are completed. Moreover, I think that we should minimise the impact of these changes so that most users will hardly notice the feature was added, in case they don't want it. Therefore, parent and child tickets should be treated exactly the same as tickets are now, with the basic modifications described below.
 
-==== Comment added by Gregory 2010.6.21 ====
+=== Comment added by Gregory 2010.06.21
+
 It would be nice if both a "related to" and a "parent/child" type of relationship were supported, the former for cases where two tickets are related -- e.g., one develops from the other -- but not nested.  The RT bugtracker actually supports three types of relationships: "depends", "refers", and "parent/child":
     * DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
@@ -10 +11 @@
     * CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.") 
 
+== Creating Subtickets
 
+As mentioned in #886, subtickets should be created by clicking an appropriate link in an existing ticket. This would pre-populate logical fields in the create ticket UI, including a free-form entry field 'parent ticket Id', just for flexibility. Also the default parent ticket should not be null, see the section below on Milestone Replacement. This field would be populated with the ticket id of the ticket being viewed when the "create subticket" link was clicked.
 
-=== Creating Subtickets ===
-As mentioned in #886, subtickets should be created by clicking an appropriate link in an existing
-ticket. This would pre-populate logical fields in the create ticket UI, including a free-form
-entry field 'parent ticket Id', just for flexibility (also the default parent ticket should not be null see the section below on Milestone Replacement). To be clear, this field would be populated with the ticket id of the ticket being viewed when the "create subticket" link was clicked.
+== Closing Parent Tickets
 
-=== Closing Parent Tickets ===
-As I see it there are three options:
+There are the following options:
   1. Allow any parent / child ticket to be closed with no consequences
   1. A cascade close where a parent ticket is closed forces a close on all its children
   1. Prevent a parent from being closed if any children are not marked completed
-I think I prefer that 3rd solution because it seems a number of people have requested this behavior (see #31)
+I think I prefer that 3rd solution because it seems a number of people have requested this behavior, see #31.
 
 [Can't these options be left flexible, so that the user has the freedom to select which s/he wants for a given parent ticket?]
 [Good Suggestion, for example when initially planning a project, some tasks including their child tasks may become obsolete, therefore closing down all of the child tasks in a single step would reduce overall work]
 
-=== Viewing Parent Tickets ===
-I think that tickets should have two views. One would be the regular ticket view, the other would
-be the milestone view with the ticket description (replacing milestone description), the completed
-status bar, and the "ticket status by field" sidebar. As Christian suggested, these should be two tabs. 
+== Viewing Parent Tickets
 
-A little off-topic, but I think that the progress bar calculation should be extendable so plugins can change how
-this works (if they want to work off different fields see TimeTracking).
+I think that tickets should have two views. One would be the regular ticket view, the other would be the milestone view with the ticket description (replacing milestone description), the completed status bar, and the "ticket status by field" sidebar. As Christian suggested, these should be two tabs. 
 
-=== Milestone Replacement ===
-Whatever changes we make in an effort to genericise milestones, we should ensure that the result is backwards-compatable with what people are using now for milestones. 
-  * Roadmap Page
-  On the roadmap page, we should display the "subtickets" tab (minus the sidebar, described above) of all tickets that have no parent. We can easily change milestones into parent tickets on upgrade, but a problem arises when a ticket has no milestone. In this case, the ticket clearly should not be displayed as a parent ticket on the roadmap page. I propose we create a special parent ticket for this with name "None" or "Future". This should also be the default for all newly created tickets so they do not automatically become top-level tickets. Then all tickets not assigned to a milestone on upgrade would be subtickets of the Future ticket, which will probably be acceptable to most users because it has a maximum impact of adding a single milestone.
-  * Milestone Details Page
-  This page is simply the "subtickets" tab described in "Viewing Parent Tickets"
-  * Milestone Dates
-  There is a problem here. Tickets currently do not have a due date, though we could fake this by adding a custom field onto all parent tickets. I would appreciate thoughts on this. Or perhaps we could add a due date to all tickets. I think this warrants some feedback from users using the milestone feature right now.
+A little off-topic, but I think that the progress bar calculation should be extendible so plugins can change how
+this works, if they want to work off different fields see TimeTracking.
 
-[a due datetime on a ticket would be fine - ''couldn't that be easily done when ticket #1942 is solved?'']
+== Milestone Replacement
+
+Whatever changes we make to unify milestones, we should ensure that the result is backwards-compatible with what people are using now for milestones. 
+
+ Roadmap Page::
+ On the roadmap page, we should display the "subtickets" tab (minus the sidebar, described above) of all tickets that have no parent. We can easily change milestones into parent tickets on upgrade, but a problem arises when a ticket has no milestone. In this case, the ticket clearly should not be displayed as a parent ticket on the roadmap page. I propose we create a special parent ticket for this with name "None" or "Future". This should also be the default for all newly created tickets, so they do not automatically become top-level tickets. Then all tickets not assigned to a milestone on upgrade would be subtickets of the Future ticket, which will probably be acceptable to most users, because it has a maximum impact of adding a single milestone.
+
+ Milestone Details Page::
+ This page is simply the "subtickets" tab described in "Viewing Parent Tickets".
+
+ Milestone Dates::
+ There is a problem here. Tickets currently do not have a due date, though we could fake this by adding a custom field onto all parent tickets. Or perhaps we could add a due date to all tickets. I think this warrants some feedback from users using the milestone feature right now. [A due datetime on a ticket would be fine - ''couldn't that be easily done when ticket #1942 is solved?'']