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

[Noah Botimer]

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