Changes between Version 4 and Version 5 of AnalyzePlugin


Ignore:
Timestamp:
Dec 11, 2011 2:36:15 AM (3 years ago)
Author:
robguttman
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AnalyzePlugin

    v4 v5  
    6161The 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. 
    6262 
     63[[Image(issue-milestone.png)]] 
     64 
    6365This 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: 
    6466 
     
    7678==== Queue Dependency Analysis ==== 
    7779The [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. 
     80 
     81[[Image(issue-queue.png)]] 
    7882 
    7983This 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: 
     
    96100==== Project Dependency Analysis ==== 
    97101This 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. 
     102 
     103[[Image(issue-project.png)]] 
    98104 
    99105This 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: