[Building Sakai] Organization and Governance (was MT deprecation recommendations for 2.7)

[Michael Feldstein]

To be honest, Chuck, I don't understand what you're talking about.

To begin with, my understanding is that the maintenance team was formed in direct response to community concerns about maintenance issues in 2.x. It consists of volunteers from the community who presumably feel that this is enough of a need for 2.x that they are willing to invest their time in it. There is nothing to maintain yet in 3.x. Likewise, the first work of those of us the Product Council, led by Clay as the Product Manager, was focused on the 2.7 release. As far as I can tell, that work has been well received by the community (although I'm eager to hear broader feedback from folks both on list and at the conference). We are only now beginning to consider how the PC should approach 3.x.

Which brings me to my next point. Nobody that I know of is arguing that the processes we have in place for 2.x will work perfectly for 3.x. Quite the opposite, in fact. We assume that they won't--at least not in a significant number of fairly obvious cases. The PC, PM, and the schools and working groups that are putting energy into Sakai 3 are in the process of trying a number of different experiments, some of which are working better than others. I assume that we will collectively decide on the "best" ways of working together based on what actually works in practice and fine tune as we go, just as we are doing with 2.x. Contrary to your view that the ongoing conversation "suggests a broken structure", what it suggests to me is a vital community that is constantly looking for ways to make its collaboration even more effective.

Finally, I find your discussion of what "Sakai 3 wants" versus what "Sakai 2 wants" to be highly unsettling. I was under the impression that we are one community working both individually and collectively to find the right balance of resource allocations between meeting present needs, represented by Sakai 2.x, against ensuring we will be able to meet future needs and fulfill a larger vision, represented by Sakai 3.x. I get the strong sense that you feel differently. For example, you write in your blog post on this topic[1], "I see a tendency for people who see themselves as community leaders conveniently conflating the "community will" with their own local risks and issues." That's a pretty serious concern, and if it is shared by a significant portion of the broader community then it is vital that we air those concerns on list so that we can make sure that the Foundation is going in a direction that the community wants it to go.

These are all important issues for the community to have dialog around. So I ask the following questions of the broader lists:

- Ignoring completely Sakai 3 for the moment, how do people feel about the development and maintenance process that we have in place for 2.x? What is working, what isn't, and what is the jury still out on?

- How do you feel about Sakai 3 in terms of its role in the future of the Sakai community? Is it an interesting experiment? A vital next step? Something in between? Do you see it as a separate project, completely independent from Sakai 2, or more interrelated than that?

- What concerns/anxieties do you have about the balancing of resources between Sakai 2.x and Sakai 3.x that are being done both by individual schools and by the Sakai Foundation? What can we do, both individually and collectively, to find the right balance, both now and in the future?


- m



[1] http://www.dr-chuck.com/csev-blog/000708.html


-----Original Message-----
From: csev [mailto:csev at umich.edu] 
Sent: Saturday, March 13, 2010 12:36 PM
To: sakai-dev Developers
Cc: production at collab.sakaiproject.org
Subject: Re: [Building Sakai] [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)


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.

As I listen to this, it all simply seems too complex - particularly for Sakai 2.x.  Sakai 2.x is a mature and stable open source product with solid rhythm and an annual release.  There are about 20 people deeply involved in fixing bugs and moving the product forward and getting releases out.  I love the notion of some strategic 2.x code cleanup and would like to see a place where the 20 people that are working on 2.x could coordinate with each other so we don't open too many construction projects at the same time.  Communication and coordination are really valuable and necessary and the folks doing the work will naturally want to talk to each other about this.

It seems like we spend way too much time debating the "purpose and authority" of the PC, PM, and MT.  That alone suggests a broken structure.

I would suggest that we move 2.x toward a situation where a single named "group/committee/etc" is where 2.x decisions are made - maintenance, release, everything.  Like an Apache PMC for 2.x.

If Sakai 3.x wants layers of management and multiple interlinked committees to guide its progress and a marketing plan etc etc - that is their choice.  I don't personally like that approach to software development and so I can choose not to work on 3.x.  If there was s single place that 2.x was discussed - I would probably join that group as I am quite interested in Sakai 2.x for the long-term because I think that many schools will be running Sakai 2.x for the next 7-8 years and so some investment in 2.x will be warranted for some time.  

I would like to see us starting to apply different approaches to structuring our 2.x effort and 3.x effort - they are at such different phases in their life-cycles and to attempt to come up with the "one true management structure for all time" - seems to be an impossible task - so perhaps we should just accept the fact that 2.x and 3.x are *different* and separate structures for each and let those structures be controlled by the people in the structures and meet the needs of the people doing the work in each activity.

/Chuck
_______________________________________________
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"