Changes between Version 5 and Version 6 of ChildTicketsPlugin/Examples

Timestamp:

May 22, 2015, 10:37:10 AM (9 years ago)

Author:

figaro

Comment:

Cosmetic changes

ChildTicketsPlugin/Examples

@@ -1 +1 @@
 [[PageOutline(2-5,Contents,pullout)]]
 
-== Examples ==
+= ChildTicketsPlugin Examples
 
-== NOTE: New 'look and feel' For 0.12 ==
+== New 'look and feel' for Trac 0.12
 
-Since trac 0.12 has the nice looking 'collapsible' areas for 'Attachments' and 'Modify Ticket' sections, I have decided to use these for the child ticket tables. It is now possible (and looks much nicer, I think!) to hide the child tickets as they are incorporated into there own collapsible section.
+Trac 0.12 and above has the nice looking 'collapsible' areas for 'Attachments' and 'Modify Ticket' sections. These can be used for the child ticket tables. It is now possible (and looks much nicer!) to hide the child tickets as they are incorporated in their own collapsible section:
 
 [[Image(wiki:ChildTicketsPlugin:NewChildTicketTable.png,border=1)]]
 
 
-=== Handling multiple bug-fixes for single bug-report ===
+=== Handling multiple bug-fixes for a single bug-report
 
-In my last job using trac with svn, we had a branch of development for each milestone of development plus a 'special' milestone to assign for hotfix/patches. Rather than creating a single 'bug-fix' ticket and commenting on the ticket that the fix had been applied to milestone X on branch X, milestone Y on branch Y, etc..., we would create a single 'bug-report' ticket (with version info but no milestone) and this ticket would, after assessment from developers/project-mgr, have a bug-fix child-ticket created per milestone - each with its own life-cycle, priority, (sometimes) developer, etc ... 
+Suppose you have a development branch for each milestone plus a 'special' milestone to assign for hotfix and patches. Rather than creating a single 'bug-fix' ticket and commenting on the ticket that the fix had been applied to milestone X on branch X, milestone Y on branch Y, etc, we would create a single 'bug-report' ticket with version info but no milestone. This ticket would, after assessment from developers/project-manager, have a bug-fix child-ticket created per milestone, each with its own life-cycle, priority, developer, etc:
 
 [[Image(wiki:ChildTicketsPlugin:bug-report-example.jpg,border=1)]]
 
-=== Handling sub-tasks from a single issue ===
 
-Probably self explanatory: you have something that needs to be done by several different people. Split it up into sub-tasks.
+=== Handling sub-tasks from a single issue
+
+Suppose you have a requirement that needs to be done by different people. Split it up into sub-tasks:
 
 [[Image(wiki:ChildTicketsPlugin:issue-example.jpg,border=1)]]
 
-=== A New Feature generates bugs ===
 
-When developing a new feature (a single ticket), our developers would 'finish' the feature and pass it to our testing department. The feature, on the whole, might be OK but require several days testing. Within that time several bugs are generated as a direct result of this new feature. It makes no sense to pass the original feature ticket back to the developers (the feature has not been 'rejected' and is still in testing!), so instead, the testing tem can make 'bug-fix' child-tickets for this parent ticket. The feature might even be released with known bugs but at least they're recorded and owned by someone/somewhere!
+=== A new feature generates bugs
 
-=== Using the 'parent.type.restrict_child_type' Option ===
+When developing a new feature (a single ticket), developers would 'finish' the feature and pass it to the testing department. The feature, on the whole, might be OK but require several days of testing. Within that time several bugs are generated as a direct result of this new feature. It makes no sense to pass the original feature ticket back to the developers, because the feature has not been 'rejected' and is still in testing. So instead, the testing team can make 'bug-fix' child-tickets for this parent ticket. The feature might even be released with known bugs but at least the are recorded somewhere and owned by someone.
 
-If you are using the above option, the available child types will be rendered as individual buttons.
+=== Using the 'parent.type.restrict_child_type' Option
+
+If you are using the above option, the available child types will be rendered as individual buttons:
 
 [[Image(wiki:ChildTicketsPlugin:MultipleChildType.png,border=1)]]
 
-=== Creating a Progress Bar for Child Tickets ===
+
+=== Creating a Progress Bar for Child Tickets
 
 If you have a lot of child tickets for one parent, and want an overview of those tickets, you can use the ProgressMeterMacro as provided by [wiki:qwp0]. In order to use this, simply provide the 'parent' as the only search query. For example, if you put the following macro definition in your ticket description: