This is a Strawman for Technical Governance based on the initial proposal made by John Norman at the Amsterdam Planning Meeting, the essence of which is below.
Technical Governance Principles
These principles are the way in which we as developers work as a community to deliver Sakai releases to the community so that the institutions that we work for can benefit from those releases. These principles are intended to guide us as a community towards those ends and by following these principles make us operate more efficiently with lower risk to ourselves, the community and our organisations. From these principles we will as a community, using the expertises within the community, build as set of best practices which will be iteratively reviewed at the projects planning meeting after each release. The principles are aimed at consensus building rather than vesting control in a subset of the community. All principles should be assessed in terms of the extent to which they foster consensus and collaboration.
1. It is in the interest of the whole Sakai community that mechanisms for encouraging consensus and collaboration should exist and be effective
The idea is that some moderation of the extremes of the 'Bazzar' will result in more effective development and more efficient deployment of resources. This principle should be embraced with caution given the pace of innovation in the sector, but on a time horizon of 2-3 years this is probably a reasonable proposition.
2. A group of peer-elected representatives has the right combination of technical understanding and referent authority to promote consensus and collaboration in the Sakai Community
Although individual 'benevolent dictator' is a common model in open source communities, we believe that the institutional dimension in our community source effort that is Sakai, will benefit from a group structure to ensure channels for multiple voices to be heard and represented and that balanced decisions are taken.
3. The purpose of the group should not be to take arbitrary decisions, but to determine when it is appropriate for choices to be made and to ensure that when choices are made, they are made with as much consensus and community support as is possible
The point here is to help the community advance by clarifying the issues around which there is consensus and highlighting the areas in which diversity and risk is still high. The group discussed here is the natural holder/maintainer of the Sakai roadmap.
4. Some form of polling is likely to be necessary to discover/reveal community views, but voting as a decision making process will be used sparingly in favour of consensus building.
We will be more effective if we work on aligning our approaches rather than setting up 'winners' and 'losers'. This will be especially important in promoting cross-institutional support for parts of the code base.
The following section is enirely my (Ian Boston) suggestion proposed as the starting point for what that commity might advise.
1. We aim to build an agile framework that enables rapid and efficient development of features in Sakai.
From 2.4 forwards we will always aim to improve the code base to make development and maintanence of tools, components and services within sakai lower cost and easier whilst ensuring that performance and stability in production improves at every release. There will be a roadmap that reflects this aim, the Technical Governance Committee will ensure that this Roadmap exists, but will not themselves do the work.
2. Trunk will become the release.
The trunk of Sakai will become the release and hence anything that goes into trunk must have an understood, recorded (Jira SAK) and sufficiently low risk profile by the team responsible for that portion of the trunk code.
3. All other work will be done in a branch.
All development work that does not fit into trunk shall take place in a branch and there will be a JIRA based process for requesting and managing the lifecycle of a branch.
4. As a community we will peer review and vote
Work that has been undertaken in a branch, will, once the team working on that branch are ready, be evaluated for merging back into trunk by a process, which will culminate in the community voting over a reasonable period of time. (ie not less than 24 hours, depending on collective understanding of risk)
5. We will justify our votes against community best practice.
As a community, anyone is able to vote, but negative votes must be justified and that justification should include the conditions under which the member of the community will change their vote to positive. Votes and justifications will be made in the light of best practice. Where there is no best practice we will use our common sense.
6. Best Practice will be developed and communicated by expert groups.
These expert groups will develop best practice based on a well understood and communicated scope of their expertiese. They will be aware of other groups and where there work overlaps actively engage with the relevant groups to achieve a common and uniform understanding.
7. The team responsible for trunk will take the final decision to merge
The team responsible for trunk will evaluate the votes, accept the comments and have the power to reject those votes that in their opinion are not justified. That team will be able to weight the votes depending based on justifications against Best Practice. That team will then have the final say since it will be that team that will be expected to make trunk work in release and have to stand before the community and organisations when it does not work in release.
8. We will review and improve without blame at the Project Planning Meeting after each release.
At the Project Planning Meeting we will review how the decisions and risk assessment made by the teams responsible for trunk in the light of the full release cycle. Informed by this, we will improve the decisions made about trunk, how each trunk area relates to the releases and where necessary add people to trunk teams. We will review the Voting process and where necessary and not already done by the Expert Groups we will ask for guidance in the form of revised or enhanced Best Practice. We will review the work of the Expert Groups and the membership of the Expert Groups will change. We will review and improve these principals. The members of the Technical Governance Committee will be closely informed by the recommendations for improvements arising from each release cycle.