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

[Anthony Whyte]

I should note that if I was going to shrink the list of statuses below  
(I like as few steps as possible) it would go with:

Open
Test
Merge
Closed
Reopened
Suspended

Cheers,

Anth


On Aug 21, 2009, at 10:04 AM, Anthony Whyte wrote:

> I'd like to see the target version restored for planning, scheduling  
> and as an indicator of where finished/fixed code needs to be merged  
> (rather than the current custom *.x status dropdowns).  This would  
> be coupled with a revised status workflow that would include steps  
> resembling the following:
>
> ___________________
>
> Open
>
> Work in progress ("in progress" does exist)
> Work suspended
> Work resumed [perhaps redundant, just reset to "work in progress" if  
> previously suspended]
>
> [Review requested
> Review started
> Review completed]  [perhaps a set of "review" phase statuses is  
> overkill (could be construed as part of "work" above) but then  
> again . . .]
>
> Testing requested
> Testing started
> Testing completed
>
> Merge requested (this step might involve merging to multiple branches)
> Merge started  [not sure we'd ever use this one]
> Merge completed
>
> Closed [means done, fini, for the history books, all workflow  
> actions completed, time for a Theakston's Old Peculiar or sleep]
>
> Reopened
>
> ________________________
>
> The K2 team has developed a set of workflow statuses similar to this  
> and I like how they are approaching the challenge of tracking tasks  
> through their life cycle; although I should note that they do not  
> use a target version.
>
> So restore the target version, revise the 2.x workflow, eliminate  
> the custom *.x branch status fields -- made redundant by restoration  
> of target version and revised workflow statuses and continue work on  
> streamlining and simplifying as much as is possible our issue  
> tracking workflows.
>
> By the way, it's not hard to check the change history to check the  
> workflow on an issue and ensure that, for example testing has been  
> completed before a branch manager or myself honor a merge request  
> but I'd need the target version set correctly to know where I should  
> merge the code (acknowledging of course that it's usually obvious)  
> without those pesky custom *.x status dropdowns (which I would like  
> to see eliminated).  Alongside this the assignee could/should be  
> updated to reflect the person/team responsible for a given phase of  
> work.  Megan I believe has configured IU's Jira to list multiple  
> assignees--something else to look at.
>
> Finally, we should create a Jira cheat sheet so that people who use  
> Sakai's issue tracking system can quickly get themselves up to speed  
> on how it all works.
>
> Cheers,
>
> Anth
>
>
> On Aug 21, 2009, at 8:41 AM, Noah Botimer wrote:
>
>> Matthew,
>>
>> Thanks for the response. Notes inline below.
>>
>> On Aug 21, 2009, at 6:36 AM, Matthew Buckett wrote:
>>
>>> 2009/8/21 Noah Botimer <botimer at umich.edu>:
>>>>
>>>> This goes to a concrete suggestion, rather than to an outright
>>>> redefinition
>>>> of your goal. Three principles first:
>>>
>>> Completely agree with your principals.
>>>
>>>> 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
>>>
>>> I worry that this may make is harder to find if an issue has been
>>> fixed in a branch as you are more reliant on using JIRA to locate  
>>> the
>>> SAK for the branch rather than an issue having the same SAK across  
>>> all
>>> branches and msub spaces.
>>
>> I am somewhat concerned about this myself but I'm not sure if it's as
>> big as we might imagine. At worst, we could use guidelines like
>> including both numbers in commit comments. At best, it might clarify
>> the logs some by avoiding the large numbers of "duplicate" changes
>> tracked on a ticket (if we didn't include both numbers). i haven't
>> formed a final opinion here.
>>
>>>
>>>> 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
>>>
>>> Sorry I don't follow, could you explain what you mean by this
>>
>> I mean that we need a clear definition of what the "right" Fix
>> Version is for intended outcomes. If we follow through on our
>> intentions, there is no post-management of the ticket required.
>> Tickets and filters would become more stable over the release cycle
>> and be automatically correct in the nominal case (file w/targeted
>> version(s), commit, verify, close ticket).
>>
>> The QA/release task becomes verifying the work and only changing
>> versions on the tickets that were wrong (missed a release, indicated
>> by an unresolved status; wrong version; had to roll back). We
>> shouldn't elect for setting things we know someone will have to fix
>> down the line, but prefer cases where someone applies minimal or no
>> change when the right things were done before them (e.g., closing the
>> ticket with a verification comment).
>>
>> In our community, the folks closest to the work are pretty well
>> attuned to what should be targeted where. I have faith that the core
>> workers on an issue can get it right in the vast majority, provided
>> there is a clear process and a very simple cheat sheet.
>>
>> Thanks,
>> -Noah
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
>>
>>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090821/b5825a55/attachment.bin