[WG: Sakai QA] Jira process clarification and modification - "Target Version"

Fri Aug 21 00:46:59 PDT 2009

Hello Pete,

I am very sympathetic to this idea [2]. I am also grateful for your  
efforts to rationalize our practices. However, I have to resist this  
proposal, at least as an immediate change.

As I am sure you are aware, we've tried a Target Version field  
previously (see references). It seems to come up around every  
summer / pending code freeze and didn't work out well last time.

After much personal deliberation, I'm still not entirely convinced  
either way. But, as a counterproposal, I offer the following:

I now believe that our confusion is not primarily due to a lack of  
fields, but a lack of clear, intuitive guidelines. For example, many  
issues are fixed in trunk and left as Open or Resolved until they are  
merged to 2.5.x or 2.6.x, while many are marked Closed. We have  
confusion built into how we handle the Status, Resolution and Merge  
Status, not just the versions.

We also have a distributed enough community that setting up paths  
through deferred, central gates is unrealistic. The reality is that  
we have smart, responsible people who do great work and get busy on  
other things. We need to entrust them with the code and tools they  
touch daily. It seems counterproductive to hope for someone else to  
retrace our tracks, find our tickets, rediscover the true status,  
merge our fixes, and twiddle some JIRA bits. Monitoring and  
reconciling the outlying errors rather than using complex rules and  
forced hand-offs is more practical and, frankly, more respectful of  
our valued colleagues and contributors.

This goes to a concrete suggestion, rather than to an outright  
redefinition of your goal. Three principles first:

   1. I believe that we need to use the Status field to reflect  
definitively whether work is pending, in progress, or completed on an  
issue. That is, Closed should mean done, period.

   2. I believe that simpler, shorter-lived tickets are easier to  
create, compare, and track through the lifecycle than long-lived,  
complex tickets tracking overlapping strands of work.

   3. I believe that we need a very straightforward map of our common  
scenarios and how an exemplary ticket in each would look, and that  
people should be encouraged to clarify and fix ones that are outside  
these lines, driving everything toward some archetype.

To meet with these principles, I suggest that we evaluate the  
following for fitness:

   1. Favoring subtasks (which may be assigned) over our merge status  
fields when something is fixed in trunk and should be included in a  
maintenance release

   2. Adding a Verified workflow state to designate work that has  
passed testing but does not reside in its final destination(s) (e.g.,  
feature branch, msub, or multi-version merge)

   3. Guiding our contributor community in setting Fix Version  
appropriately as a target for unresolved issues and allowing this to  
default into zero-touch accuracy when following through to actual  
resolution

Thanks again for carrying this torch. We appreciate the hard work you  
do for us all. I look forward to the dialogue.

Thanks,
-Noah

[1] http://www.nabble.com/Fwd%3A-Tracking-Status-of-JIRA-Tickets- 
ts10991816.html

[2] http://www.nabble.com/JIRA:-Target-Version%28s%29-recommendation- 
ts12221797.html

[3] http://www.nabble.com/JIRA%3A-New-Target-Versions-Field- 
ts12373053.html

[4] http://www.nabble.com/JIRA%3A-Target-Versions-and-Fix-Versions- 
ts12561732.html

[5] http://www.nabble.com/Jira-Tip%3A-Target-Version-and-Fix-Version- 
ts14758534.html

[6] http://www.nabble.com/Jira:-Target-Version-Field-No-Longer- 
Available-ts18557751.html

On Aug 20, 2009, at 10:51 PM, Pete Peterson wrote:

> Greetings,
>
>
>
> We have received many comments expressing confusion concerning the  
> current Jira implementation.   We are in the process of reviewing  
> Jira and workflow schemas, simplifying and clarifying the intake  
> forms, and evaluating suggestion received from Jira users. We are  
> always looking for additional feedback, suggestions and comments,  
> so please send us any ideas you may have. In the next few months we  
> will accumulate and organize the results and post them to the Sakai  
> community for review.
>
>
>
>  In the meantime there is a relatively simple change we would like  
> to implement immediately; details follow:
>
>
>
> BACKGROUND
>
> ------------------
>
> There is a great deal of confusion with the “Fix version/s” field  
> in the current Jira Schema. Sometimes it is used as a pointer to  
> the version where they would like to see the bug/task /enhancement  
> included, sometimes it is used as a bookmarker for future  
> development work, and sometimes it is left blank. This modification  
> should help clarify the use of the Fix Version/s field.
>
>
>
> PROPOSED CHANGE
>
> -------------------------
>
> * Add New Jira Field: “Target Version/s”
>
>
>
> EXPLAINATION of FIELDS
>
> ------------------------------
>
> * Affects Version/s:  Reporter files and issue report and selects  
> one of more current release/*.x branch versions to which the issue  
> applies.  The number of affected versions may be modified  
> subsequently by the assignee, project team, QA, etc. as the issue  
> is investigated.
>
>
>
> * Target Version/s: Assignee/project team indicates one or more  
> future release/*.x branch versions to which a fix is expected to be  
> applied.  The Target version offers an opportunity for assignee, QA  
> or project team to leverage Jira's scheduling and planning features  
> to target the version where the issues will be resolved.  The  
> targeted version may be changed if, for instance, the team is  
> unable address the issue in time for the specified release. The  
> Target Version/s should be set by the project, QA or release  
> management team members only.
>
>
>
> * Fix Version/s: the release/*.x branch version(s) to which the fix  
> is actually applied as the result of branch and release management  
> work.  The Fix Version/s should be set by the branch and release  
> managers only.
>
>
>
>
>
> <image001.png>
>
>
>
> Let us know if you have any comments ASAP and thank you again for  
> your help,
>
>
>
> Pete Peterson
>
> QA Director, Sakai Foundation
>
> plpeterson at ucdavis.edu
>
> Phone: +1-530-754-7259
>
>
>
>
>
> <image001.png>
> _______________________________________________
> sakai-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>
> TO UNSUBSCRIBE: send email to sakai-qa- 
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090821/9de1be46/attachment.html 