Thought Piece: Sakai Naming Practices

David Horwitz 30 May, 2009 13:05 Sakai Permalink Trackbacks (0)

As the "Sakai 3" processes role on its becoming apparent that there is a fair amount of confusion about the relationship of the 2 projects (the UX project and the K2 project) and their relationship to Sakai 3 (the next major version of the Sakia platform). Some of this confusion relates to fairly lax practices and names being used suggesting links to Sakai 3 that could be confusing to those not following the project closely.

 

Some assumption:

  1. Sakai as a product is a collection of components, as such it more closely resebles a Linux Distribution than a single application
  2. Sakai as a product is owned by the community, but managed by the soon to be constituted product council.
  3. Sakai release are managed by the release management group. 

Some things flow out of this:

  1. Sakai as a name is owned by the product council. To have a name like 'Sakai 3' or '3akai' the project must meet the product councils requirements for the name and have their approval.
  2. as such no R&D or incubation project should use names that are similar to the Sakai name or name-space.
  3. Terms like "beta" and "rc" as applied to projects that fall under 1 above are owned by the release management team. i.e. something cant be called Sakai-3.0-Beta till the release management team is satisfied that the code meets the criteria for that designation.

And some suggested best practices:

  1. All projects should be clearly named from inception
  2. Where there is a meta project that consists of two or more project (as in the current case) it should be clearly named at inception. 

comments

  1. While current Sakai 3 project naming breaches these rules, I'd point out a couple of things: 1. the naming was adopted by a large group of people at the Paris Sakai conference - a group that might not be that different to the product council today except that membership was not formalised. The product life cycle approach and the product council came after this decision. 2. the RC language was used by Foundation staff, not members of the project 3. members of the project have offered other names, but none has stuck 4. members of the project have encouraged others to work on the UX on top of Sakai 2. No institutions have yet chosen to devote resource to such an initiative. The confusion largely results therefore from one institution contributing most of the effort to both initiatives - including a large amount of largely wasted effort on Sakai 2 support for 2.6 that was requested by other institutions but not taken up. 5. I don't think that the release team is a sufficient gatekeeper for the code quality. I think we need to go further and designate a maintenance team. This team should have a big say in what code is adopted and included in 'maintenance'.

    Posted by John Norman — 31 May 2009, 12:39

  2. John, this was not intended as a criticism of the project team, who I think are doing incredible work. it was a the confusion I perceive in the community, I'm not attempting to appropriation blame (and if it sounded like that I apologize), its an attempt to learn from what's happened and suggest some practices we should adopt going forward. I'm quite aware that community practices are evolving and wrote this cognisant of those process that are in the processes of being established buta re not up and running. I agree that the release management could do with strengthening, however its an process that is well established and has successfully overseen an improvement of the quality of Sakai releases over the last several years. There are also clear precedents for what constitutes a RC release of Sakai, and I'm afraid what I've seen sakai3-rc1 described as doesn't meet it. This is not a comment on the quality of the code but simply it hasn't been through the established community process for that designation. I'm pretty confident that once the qa team get hold of it sakai3 will rapidly meet RC status but this needs to be happen before I would support it getting that designation

    Posted by David Horwitz — 31 May 2009, 17:19

  3. one thing I would add is that I firmly believe that a well defined community process should protect both the community (from risk) as well as the project team (from unrealistic or ill defined expectations)

    Posted by David Horwitz — 31 May 2009, 17:35

  4. Great post David. This is exactly why I haven't liked the 3akai name for the UX work that is fronting K2. And, arguably, the K2 name is presumptive as well. But practically speaking we aren't going to have lost of projects contending to be the new Sakai Kernel. Or the new Sakai UX framework. So I'm okay with K2 and 3akai as names for projects that are striving to be part of Sakai 3. I think we can make it clearer going forward following the conventions you suggest. I'm fearful that we sew more confusion by changing names for existing project midstream and I'd prefer to leave them as they are.

    Posted by Michael Korcuska — 31 May 2009, 17:57


Add comment

Topic

Text

Your name

Your email address (if any)

Your personal page (if any)

authimage


Powered by LifeType
© 2006 - Design by Omar Romero (all rights reserved)