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

Fri Aug 21 08:18:48 PDT 2009

I think this is a good discussion. I think we need to take a bit more  
time and that some confusion is resulting from the fact that we don't  
have a common understanding of what the work flow is (or should be).  
So I recommend starting with a plain English (no reference to Jira)  
description of what should be happening. Once we agree on that then we  
can figure out how to wrestle jira into helping us reflect that as  
simply as possible.  It would also serve as good documentation for  
newcomers.

For bug something like:

Someone identifies issue and the version(s) of the software it affects
Others verify the issue exists and examine whether it affects other  
releases/trunk
Some developer takes responsibility for the issue and lets everyone  
know it is being worked on
Developer describes fix on list and asks for approval to commit  
(possibly optional)
Developer submits a fix to the relevant branch and asks for testing
QA tests the issue and either sends it back for more work or confirms  
it is fixed
Branch managers apply fix to their branches, resolving merge conflicts  
along the way
Fix is verified in the relevant branches

I know this probably isn't exactly right, but I hope you get the  
idea.  There are other complexities like "I was working on this but  
now I'm not" that might be relevant.

The crux of the matter, I think, happens after a fix is created for a  
particular branch, say trunk. In some sense, from the developers  
perspective, that closes the issue. But there may still be work to  
apply that issue to multiple branches. And so a single bug turns into  
multiple issues to track from a QA and release perspective.  The  
branch managers and release team want to be able to figure out not  
only if a bug was fixed but whether that fix was applied to their  
branch.

Thoughts?

Michael

On Aug 21, 2009, at 07:17, Anthony Whyte wrote:

> 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"
>
> _______________________________________________
> 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"

-- 
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska at sakaifoundation.org
phone: +1 510-859-4247 (google voice)
skype: mkorcuska