[Building Sakai] [DG: Teaching & Learning] Organization and Governance (was MT deprecation recommendations for 2.7)

[Noah Botimer]

I'm going to side-step most of this on list. I think the questions at  
the bottom are fair, but I think the most important for now is:

   What do you expect from 2.8 and what are you willing to contribute  
to make it happen?


For the meat of my perspective on the whole thing, see my blog post.  
I've bolded overzealously in the call to action in lieu of a proper  
summary.

http://botimer.net/posts/2010/03/13/sakai-futures/

Thanks,
-Noah


P.S. Please note that this is emotional writing on behalf of myself  
alone -- it doesn't speak for the PC, U-M, Sakai, or anybody else.


On Mar 13, 2010, at 4:33 PM, Michael Feldstein wrote:

>
> 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"
> _______________________________________________
> pedagogy mailing list
> pedagogy at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to pedagogy- 
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>