Changes between Version 4 and Version 5 of AnalyzePlugin

Timestamp:

Dec 11, 2011, 1:36:15 AM (12 years ago)

Author:

Rob Guttman

Comment:

--

AnalyzePlugin

@@ -61 +61 @@
 The popular [wiki:MasterTicketsPlugin master tickets plugin] enables specifying dependencies amongst tickets and visualizes them via graphviz.  However, it does not provide tools to help manage these dependencies including detecting when they're not scheduled in the correct dependency order.  That's where this Milestone Dependency Analysis comes in.
 
+[[Image(issue-milestone.png)]]
+
 This analysis detects when a ticket in a given report has a dependency (a "blockedby" ticket) that is in a future milestone (or not scheduled in any milestone).  This works with either semantics for blockedby tickets:
 
@@ -76 +78 @@
 ==== Queue Dependency Analysis ====
 The [wiki:QueuesPlugin queues plugin] converts one or more reports into work queues.  These queues enable you to drag and drop tickets above and below one another signifying their relative priority.  Each ticket's relative position is maintained in a custom field usually named {{{position}}} (but can be named anything).  Dependencies amongst peer tickets in a work queue have similar problems as tickets across milestones - in this case, a dependent ticket should precede (i.e., appear higher in the queue which means have a lower {{{position}}} value), but it can be difficult to manually catch all of these dependency violations.  That's where this Queue Dependency Analysis comes in.
+
+[[Image(issue-queue.png)]]
 
 This analysis detects when a ticket in a given report has a dependency (a {{{blockedby}}} ticket) whose {{{position}}} comes after this ticket's (or has no {{{position}}} yet at all).  To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows:
@@ -96 +100 @@
 ==== Project Dependency Analysis ====
 This analysis is for ''project'' queues (instead of work queues) meaning that the dependency semantics is parent-child.  For example, you may have a report of project (or epic in agile-speak) tickets whose sub-tasks are represented in their {{{blockedby}}} dependencies.  Re-prioritizing a project/epic/parent ticket does not automatically re-order their child tickets, respectively.  That's where this Project Dependency Analysis comes in.
+
+[[Image(issue-project.png)]]
 
 This analysis will enforce that the child tickets (usually found in a separate work queue report) are ordered relative to one another in the same general order as the parent/project tickets.  To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows: