[sakai2-tcc] add Target version field in Jira?

Tue Mar 12 21:26:41 PDT 2013

I have to refer to the old threads on Target Version, which was, indeed, tried with little success. This is not to say that it couldn't work, but rather than evidence that there is a better probability of that, I think we have the opposite. There are more versions, more components, more flags, and more projects in JIRA, all while there are fewer net hours going into "project management" (a.k.a. coordination) and keeping things synchronized.

This is pretty easy to manage with the Fix Version field. Assigning and marking In Progress is also helpful. A simple heuristic may work here (though this may be a bit off):

1. Fix Version set to an unreleased version by some developer or someone who directs development speaks to a general commitment to finish something by that release. Unassigned here should imply a strategic priority with the TCC on board and seeking committed resource (if that sounds like it should be rare and a high bar, I agree -- this should be the emergency case).

2. Fix Version set to unreleased and marked In Progress signals active work to address an issue for said version.

3. Fix Version set to a release version while ticket is unresolved approaching release indicates a collision of intention and reality -- contact needed, either to inform of a deadline or figure out time/help needed in the case of an essential fix.

4. Fix Version set to release version while ticket is unresolved after release indicates an incorrect ticket (finished, but unmarked) or a decision to release without said issue addressed (ticket incorrect by not reflecting decision) -- should be deferred one version if work is ongoing or imminent, or unset if resources never arrived or were redirected.

Moving on to my usual "broader point"...

We need to get over the impression and behavior that maintenance releases are momentus. Keeping everything on hold because we're "going to get a few more issues addressed soon" sets up almost infinite wait conditions in our pipeline. Slip begets slip, exception begets exception and everyone gets frustrated -- unless we are diligent to lock down either scope or schedule approaching releases.

There'll be another release. Your fix will get picked up some time after it's done. No big deal. Any pressure should be about the nature of an issue, not artificial grandure of a release or uncertainty of schedule. It's surprising how effective a dependable release cycle and pattern is in helping to focus priorities and deliver to a plan rather than slipping on best intentions. A pattern of "just kidding, we're extending again" drives exactly the opposite, resulting in people not taking the schedule seriously, feeling futility of delivering fixes against artificial deadlines, and general ineffectiveness in a drawn out, nagging process.

I think prospective release notes / changelog and a planned schedule, in one readable page go to the goals much more effectively than a Target field or any additional JIRA gymnastics. If the changelog is wrong, people will find and fix the info gathering process that made it wrong. Worst case, we have somewhat better information (by collation alone). Best case, we have great information people can use to plan local development and upgrades as well as understand and adjust community expectations on them.

Remember, repeated execution is what makes a pattern work. I personally think the majority of our chaos comes from incrementally adding complexity rather than reducing it -- too little holds constant between cycles that are too far apart for us to establish anything that resembles a pattern.

Thanks,
-Noah

P.S., I make no claim that I have not added complexity. I argued for adding Target Version years ago and made a few half-steps in cleaning up POMs for 2.9, both of which changed things but did not ultimately reduce our complexity or help us deliver quality releases on time. All of my current initiatives have a primary goal of reducing net complexity. I encourage everyone to focus on this kind of "community refactoring".

On Mar 12, 2013, at 10:25 PM, Neal Caidin <nealcaidin at sakaifoundation.org> wrote:

> I don't think the merge fields quite do the trick because they only indicate the merge intention to a branch, not to a particular tag. And I hypothesis, but of course could be very very wrong, that adding a target version will help, over time, the data to improve, because it will make the overall process clearer. While (thanks to your help) the processes and fields among the various projects are starting to converge, but they are still different and have different management processes in place (which makes sense to some extent, since that would be the idea of an Indie).
> 
> -- Neal
> 
> On Mar 12, 2013, at 10:17 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
> 
>> The merge fields already address this need in my opinion (at least for
>> the CLE and KNL projects). Indies which use their own versioning are
>> not really part of the same schedule so they shouldn't be using the
>> same fields. We already have filters which use those fields and as far
>> as I can tell they work.
>> 
>> The fix version and affects version fields already tend to be wrong in
>> many cases and adding another field is just going to me more wrong
>> data.
>> Maybe a better task would be fix up all the wrong fix and affects
>> versions. After that is completed we can look at adding more fields
>> and decide how we would maintain them accurately going forward.
>> 
>> -AZ
>> 
>> 
>> On Tue, Mar 12, 2013 at 10:09 PM, Neal Caidin
>> <nealcaidin at sakaifoundation.org> wrote:
>>> Hi TCC,
>>> 
>>> This has come up before, recently I think, but I bring it up again because I think there is still a need. As I work on a query to cross projects for identify issues for qa testing, merging, etc, I still see an important use case of Jiras which it is not clear if they are intended for a particular release (2.9.2, for example), and after the fact, to identify issues that have been merged into the release (inconsistent use of fix version).
>>> 
>>> Two possible strategies, both of which seem reasonable to me are:
>>> 
>>> 1) Use of labels. The advantage of labels is that across the main project and indie projects we can use the same label to tie things together for a particular release, even with indies on different versions. One label, 292triage for example, can tie together disparate versioning conventions across MSGCNTR, LSNBLDR, BASICLTI, SAMIGO, etc. This should make it easier to do clean up on the fix version and help with queries for merging and testing (it did for me and the QA group in 2.9.1).
>>> 
>>> OR
>>> 
>>> 2) Add a Target version field in Jira, in addition to the affects version and fix version.  The advantage of a target version is that it will make it clearer which version an issue is intended to be included in (though extra translation may be needed to the overall release version) and it will also clear up confusion around the fix version, which many still use as a target version field.
>>> 
>>> If you don't like either of these ideas do you have alternatives that might address these issues? If you are not convinced there is a need, I wonder how I can convince you? Hypnotism? Psychedilics? <just kidding!> You are feeling very sleepy. Oh, wait, that's me after a large dinner. Nevermind.
>>> 
>>> Wondering if I should loop in QA and Dev groups. Folks in QA group definitely are with me on this issue, I would say.
>>> 
>>> Cheers,
>>> Neal
>>> 
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
>> 
>> 
>> -- 
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> 
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc