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

[Anthony Whyte]

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

-------------- 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/78ed8c9b/attachment-0001.bin