[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