Edgewall Software

Changes between Version 12 and Version 13 of SubTickets


Ignore:
Timestamp:
Jan 17, 2015, 4:54:10 PM (4 years ago)
Author:
figaro
Comment:

Cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • SubTickets

    v12 v13  
    1 == Subtickets Specification Proposal ==
     1= Proposal for Subtickets specifications
    22
    3 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.
     3Here 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.
    44
    5 ==== Comment added by Gregory 2010.6.21 ====
     5=== Comment added by Gregory 2010.06.21
     6
    67It 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":
    78    * DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
     
    1011    * CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")
    1112
     13== Creating Subtickets
    1214
     15As 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.
    1316
    14 === Creating Subtickets ===
    15 As mentioned in #886, subtickets should be created by clicking an appropriate link in an existing
    16 ticket. This would pre-populate logical fields in the create ticket UI, including a free-form
    17 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.
     17== Closing Parent Tickets
    1818
    19 === Closing Parent Tickets ===
    20 As I see it there are three options:
     19There are the following options:
    2120  1. Allow any parent / child ticket to be closed with no consequences
    2221  1. A cascade close where a parent ticket is closed forces a close on all its children
    2322  1. Prevent a parent from being closed if any children are not marked completed
    24 I think I prefer that 3rd solution because it seems a number of people have requested this behavior (see #31)
     23I think I prefer that 3rd solution because it seems a number of people have requested this behavior, see #31.
    2524
    2625[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?]
    2726[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]
    2827
    29 === Viewing Parent Tickets ===
    30 I think that tickets should have two views. One would be the regular ticket view, the other would
    31 be the milestone view with the ticket description (replacing milestone description), the completed
    32 status bar, and the "ticket status by field" sidebar. As Christian suggested, these should be two tabs.
     28== Viewing Parent Tickets
    3329
    34 A little off-topic, but I think that the progress bar calculation should be extendable so plugins can change how
    35 this works (if they want to work off different fields see TimeTracking).
     30I 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.
    3631
    37 === Milestone Replacement ===
    38 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.
    39   * Roadmap Page
    40   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.
    41   * Milestone Details Page
    42   This page is simply the "subtickets" tab described in "Viewing Parent Tickets"
    43   * Milestone Dates
    44   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.
     32A little off-topic, but I think that the progress bar calculation should be extendible so plugins can change how
     33this works, if they want to work off different fields see TimeTracking.
    4534
    46 [a due datetime on a ticket would be fine - ''couldn't that be easily done when ticket #1942 is solved?'']
     35== Milestone Replacement
     36
     37Whatever changes we make to unify milestones, we should ensure that the result is backwards-compatible with what people are using now for milestones.
     38
     39 Roadmap Page::
     40 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.
     41
     42 Milestone Details Page::
     43 This page is simply the "subtickets" tab described in "Viewing Parent Tickets".
     44
     45 Milestone Dates::
     46 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?'']