[sakai2-tcc] Cross cutting concerns and prompt patching during a major release

[csev]

I was thinking about this some more and came up with the following idea.  I think that one of the ideas this discussion is trying to get its hands around is quicker throughput for patches that are ready to go.   The proposed process feels like an "escalation process" which probably is not really necessary.

As a project lead myself, I would *love* to have a nice, simple place I could look for patches that are considered "trunk-ready" - this would be very useful for me - I would have a few hours of time and ready to clean up so low-hanging fruit - I would go and look for these easy wins and review and commit them.

So I propose the follows:  Add (yet another) drop down to JIRA similar to the "Which branch(es) to put this in" to allow anyone to create and/or edit a JIRA and indicate that in their opinion this JIRA and its patch is good quality and just needs to be put in trunk.  The drop down should be three-states - trunk-ready/not-trunk-ready/applied

I could make a filter in Basic LTI and Portal that I could pull these up easily and separate the low-hanging fruit from the harder stuff that will take more time.

And if I take a look and disagree, I simply edit the JIRA with a note as to how and why I think this is not trunk ready and we have a dialog right there in JIRA for all to see and nicely recorded in the right place.   Just like a branch merge - things might go back and forth a bit.

Or perhaps the initial committer did not indicate "trunk ready" and a QA sweep goes through and thinks it is trunk-ready, and indicates as such and thus begins the interaction.

I think this is cool as heck and would be really useful for me as a project lead.

I think that this discussion talks about a second problem that to me is very independent - the problem of unresponsive project leads.  Again, this is pretty independent - and this is why we have the MT - at some point if a lead sort of retires and becomes completely unresponsive, the TCC and MT can then step in.  The MT scope is as wide as it likes but it is natural for it to focus on the fallow parts of the code base.   I think that when anyone gets the feeling that there is no one home in some project, then we should have a discussion in the TCC and MT to get a handle on things and figure out the best way forward.

But these discussions are quite different than a discussion about a single patch not moving quickly enough - I think that the "Trunk Ready" flag is a great solution for that - a solution that makes thins easier, smoother, and less confrontational.

/Chuck