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

Michael Korcuska mkorcuska at sakaifoundation.org
Fri Aug 21 14:56:16 PDT 2009


This is exactly my point. Without a clear "real world" workflow we  
won't be able to make Jira clear. As I've said before, a clear user  
interface doesn't hide the complexity of the underlying model but,  
rather, reveals the clarity and simplicity of that model.

I don't have (much) a stake in what the workflow is. I just don't  
think we should make substantial changes to jira without being clear  
about what workflow(s) it is supporting.  Please don't misunderstand  
me, I *do* think we should make changes to jira. It is worth some time  
to think it through.

Michael

On Aug 21, 2009, at 12:59, Anthony Whyte wrote:

> It might do well to unpack the discussion still further and ask if  
> our current assumptions regarding the value of the gate keeping  
> embedded in the workflow outlined below still makes sense.  Branch  
> management gate keeping, for instance, is currently practiced as a  
> part-time occupation by a few hardy community souls who volunteer  
> their time to merge fixes into our *.x maintenance branches.  This  
> is an important task without which we could roll no releases.
>
> Unfortunately, verified fixes ready for merging are often forced to  
> queue up for rather long periods of time while the few branch  
> managers we have available labor to process merge requests while  
> juggling their other commitments.  Many of these merge requests  
> could in fact be handled by the originating project teams themselves  
> with little risk to the target maintenance branch.  Tested and  
> verified fixes could be brought to market faster and branch managers  
> could instead focus on general branch oversight and coordination  
> activities.  If, as in the case of 2.6.x, we raised the portcullis  
> currently defending the maintenance branch and permitted project  
> teams to merge their own tested and verified fixes we could reduce  
> dramatically the current backlog of fixes queued up to be merged  
> into 2.6.x (170+ issues by my count).
>
> Branch oversight is important but if we practice it in a way that  
> impedes the otherwise quick delivery of verified and tested fixes we  
> gain no advantage.
>
> Cheers,
>
> Anth
>
>
> On Aug 21, 2009, at 11:18 AM, Michael Korcuska wrote:
>
>> 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
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> 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






More information about the sakai-qa mailing list