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

[csev]

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