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

[Anthony Whyte]

In other words, imagine the portfolio team with the puck in the  
offensive zone with an opportunity to score.  Why force them to dish  
the puck off to a branch manager back on the blue line when Beth  
Kirschner is in position to top-shelf the goalie with a wrist shot  
from just above the circle?

I think she should take the shot.

Anth



On Aug 21, 2009, at 7:16 PM, Noah Botimer wrote:

> I see this as strikingly accurate and exceedingly valuable.  
> Monitoring makes more sense in most cases than gate keeping. The  
> kernel is most sensitive and already handled with some additional  
> guidelines and care. Cross-module dependencies are next and require  
> some level of cooperation, but I wouldn't say they beg for central  
> administration.
>
> For modules with no inward dependencies, I see limited value in  
> handing things off for the sake of handing them off. The folks who  
> apply fixes are usually the closest to the knowledge of how things  
> should work out. They are also the ones who are ultimately  
> responsible for the well-being of that module. The ability to merge  
> closer to the time of fix, by more familiar hands, is valuable for a  
> raft of sanity and quality reasons. It's also worth noting that none  
> of this requires that we lose any visibility of, or ability to raise  
> issue with, changes going into maintenance branches.
>
> If I were cheeky on a Friday evening, I might say that oversee is  
> the right verb, not overdo.
>
> Thanks,
> -Noah
>
> On Aug 21, 2009, at 3:59 PM, 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>

-------------- 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/e2ff29b2/attachment.bin