[Building Sakai] [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)

[John Norman]

On 13 Mar 2010, at 17:36, csev wrote:

> 
> 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 wonder? I do spend very little time discussing "purpose and authority" of these groups. Their authority is very limited, we are an open, consensus-driven community, their purpose is to provided a focus and support for the open-community process. It is true that many in the community look for authority, some because they welcome it some because they want to reject it. In truth it is not there.
> 
> 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.

I would not reject that. In many ways we are almost there. The release team is focussed on Sakai 2 because Sakai 2 does releases. The maintenance team is focussed on Sakai 2 because Sakai 2 has something to maintain. Only the product council and PM overlap, and that is because at least some in the community want the thinking around 2 and 3 to be joined up, but 80% of the PC discussion so far has been about Sakai 2 and I would guess at least 50% of the effort of the PM.
> 
> 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.  

You mention elsewhere that Sakai 2 is at a different stage in its life cycle, but it passed through a managed development phase (for better or worse). Most of the conversation about authority and structure (that I am involved in) anticipates a similar *transitory* phase for Sakai 3.
> 
> 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.

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.

John
> 
> /Chuck

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.