Changes between Version 40 and Version 41 of AnalyzePlugin

Timestamp:

Sep 14, 2016, 9:37:38 PM (8 years ago)

Author:

figaro

Comment:

Further cosmetic changes

AnalyzePlugin

@@ -16 +16 @@
 See below for examples.
 
-[[Image(ask_analyze.png)]]
+[[Image(ask_analyze.png, border=2)]]
 
 == Bugs/Feature Requests
@@ -70 +70 @@
 The popular [wiki:MasterTicketsPlugin master tickets plugin] enables specifying dependencies amongst tickets and visualizes them via graphviz.  However, the plugin doesn't include support to manage these dependencies such as detecting when tickets are scheduled out of order. That's where this Milestone Dependency Analysis comes in:
 
-[[Image(issue-milestone.png)]]
+[[Image(issue-milestone.png, border=2)]]
 
 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 of the following semantics for {{{blockedby}}} tickets:
@@ -89 +89 @@
 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, ie 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)]]
+[[Image(issue-queue.png, border=2)]]
 
 This analysis detects when a ticket in a given report has a dependency, for example a {{{blockedby}}} ticket, whose {{{position}}} comes after this ticket's or has no {{{position}}} yet at all, or is not in the correct queue. To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows:
@@ -118 +118 @@
 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 Queue Analysis comes in:
 
-[[Image(issue-project.png)]]
+[[Image(issue-project.png, border=2)]]
 
 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:
@@ -145 +145 @@
 This analysis summarizes a project by "rolling up" its child tickets using one of several statistical methods. For example, you may have a report of project (or "epic" in agile-speak) tickets whose sub-tasks are represented in their {{{blockedby}}} dependencies. You would like each project ticket's fields to summarize (or roll up) those of its child tickets. That's where this Project Rollup Analysis comes in:
 
-[[Image(rollup-project.png)]]
+[[Image(rollup-project.png, border=2)]]
 
 To enable this analysis for reports, list those reports in {{{trac.ini}}} as follows: