I was going to write a long message to John Norman about wishing for a 2.x PMC that functioned without higher-level priority setting authority and came across this note from John to Clay and Anthony on January 24 about the Maintenance Team:

“My instinct also is to avoid formality unless it is shown to be needed. Why don’t we just proceed with these people acting in a broadly similar way to an Apache PMC (which allows for anyone to be out of contact for a period) and see if that is good enough. I’m more interested to know if the maintenance team has managed to get any bugs fixed and what issues are concerning them with regard to their mission to improve the code.”

Once I saw this, I realized that I could not say it any better than John already had said.

The message I did not send

On Mar 13, 2010, at 4:03 AM, John Norman wrote:
Personally, I see it as a valuable function of the MT to ‘tidy up’ the code base. I am not sure I care when a decision is made so long as (a) it is properly discussed and consulted on and (b) all decisions that affect a release are reviewed at the same time. So I can view this as early opening of the consultation (good) and potentially a process that allows decisions to be reviewed carefully without rushing (also good). So, while I accept Stephen’s point, I think I might advocate that we don’t wait to consider such issues, but we do insist that they be recommendations and if acted upon (e.g. for testing dependencies) they should be reversible until the tool promotion decision point.
It feels like the PM and/or Product Council should be able to help here

I don’t see the ambition for the structures that you attribute to them. I think we are seeing incremental steps to fill gaps and respond to community needs. Of course if you don’t share those needs it may be hard to empathise and my own view may not be that of other participants in the efforts, but I have none of the intent that you seem to rail against.

Chuck’s Response:

John, the thing I rail against is the statement you made above – “It feels like the PM/PC should be able to help here”. I interpret (and I think others do as well) that statement as “perhaps the MT should get approval from the PM/PC in order to properly set overall priorities for the community”. What bothers me is that I see a PM/PC structure that seems primarily set up for Sakai 3.x having “authority” over a structure that is set up for Sakai 2.x simply because 3 > 2.

By the way – I am not sure that the MT in its current form *is* the right place for these 2.x discussions either – what I dream of is one place where 2.x is the sole focus – not four places where 2.x is partial focus. I want separate but equal – I want 2.x to be able to follow its own path without priorities and choices about 2.x being made from the perspective of “what’s best for 3.x”. I want a win-win situation not a one-size-fits-all situation.

I *do* want to make sure that things get added to 2.x in order to make 3.x happen as effectively as possible – as a matter of fact my own contributions in 2.x in the past few months have been heavily focused improved connectivity between 3.x and 2.x and I am really excited about the progress and looking forward to when 3.x runs on my campus. Even in some future state after my campus is running Sakai 3.x in hybrid mode and I am happily using it as a teacher, and perhaps I have even become an active Sakai 3.x contributor, I *still* will be opposed to structurally viewing Sakai 2.x priorities though a Sakai 3.x lens in the name of “overall brand consistency”.

And interestingly, if *I* think that the PC/PM is a group that cares mostly about 3.x and you think that the PC/PM cares mostly about 2.x – that itself is an interesting question. Particularly because you are a member of the PC and I am a confused 2.x contributor. :)

On Mar 14, 2010, at 5:39 AM, John Norman wrote:

PS I have long held that Sakai is a community of institutions, rather than a product. I think the efforts look a little different through that lens.

Chuck Wrote:

For Sakai 3.x, I think that it *is* a community of institutions and that is a pretty reasonable structure for Sakai 3.x at this point in its lifecycle – and for Sakai 2.x I think that it is a community of individuals at this point in its lifecycle and that is the perfect structure for Sakai 2.x at this point in time. *Neither is wrong* – it is the nature of the development phase of each project – and why I am uncomfortable with to our current PC/PM “one-committee-to-rule-them-all” governance (or perceived governance).