Sakai
...
Project Team Organization
...
Purpose
...
and Governance
Sakai Project Management Committee (SPMC)
Sakai Project Management Committees (SPMC) exist to oversee the design and development of core Sakai projects. More specifically, SPMCs provide overall project leadership, decision-making, review and team coordination and collaboration. SPMCs are established formally by the Sakai Executive Director and can be dissolved by the Executive Director subject to Sakai Foundation Board oversight.
SPMCs are composed of a minimum of three (3) members, one of whom serves as chair of the committee. Initial SPMC membership is determined by a majority vote of Sakai Community members, the mechanisms for which is determined by the Sakai Executive Director.
The SPMC chair's role is that of facilitator rather than leader. The chair ensures that discussions are open, decision-making is transparent and that SPMC practices are aligned with general Sakai Community processes. The chair is responsible for providing timely project updates to the Sakai Project Coordinator and participating as necessary in release management discussions.
_________________________
Description
One of the major goals of the Sakai Foundation is to produce production-quality collaboration and learning software. This document describes how this activity is organized and provides some guiding principles around how the Sakai software is developed. This document only covers software projects - not the other activities within the Sakai Foundation.
...
As a result of this additional need for a unified, production-quality distribution across projects, Sakai requires additional choreography and orchestration across projects that are unnecessary in Apache. Where this choreography is needed in Sakai the attempt is to add it in a way that is true to the proven Apache principles guiding projects.
Guiding Principles
There are a number of guiding principles that underlie this document. This section attempts to capture the nature of these concepts.
Constant Communication
This is the foundation of informed collaboration between intelligent people, and in a community of cooperating projects, communication is the key to understanding and effectively pursuing any and all activities within that community. It is a requirement for an organization that must bring together a variety of complex components into a working whole, and reflects our experience that successful volunteer collaborations are built on the contributions of informed individuals who have common goals but often wildly different styles of working and problem solving. Constant communication keeps the necessary descriptions and explanations flowing and available to everyone.
We consider this one of the principles that should be followed in all the various venues and efforts that make up the Sakai Community.
Meritocracy
From Apache: We call this basic principle "meritocracy": literally, governance by merit.
...
Reference: http://www.apache.org/foundation/how-it-works.html#meritocracy
Openness
While PMCs in Sakai are given broad powers to control their own destiny, it is critical for them to do their work in the open. Without openness, there is no way to harness the talent of the entire community and no good way for new members of the community to come up to speed so they can contribute.
...
Reference: http://www.apache.org/foundation/how-it-works.html#management
Sakai Software Projects
Much like the Apache Foundation, Sakai's software effort is divided into projects. Each software project within Sakai is governed by a Project Management Committee (PMC), which is composed of the committers for the particular project. The PMC chair for a project is the lead committer for the project. The Sakai Foundation board delegates the technical decisions for each software project to the PMC for that project.
...
Apache reference: http://www.apache.org/foundation/how-it-works.html#structure
Roles Within Project
The Chief Architect, Project Coordinator, Release Manager, and QA director are the cross-project roles and as such there are no equivalent roles to be found in the Apache Foundation. Within a Sakai project, however, the structure and terminology is identical to the Apache Foundation.
Apache reference: http://www.apache.org/foundation/how-it-works.html#roles
User
From Apache: A User is someone that uses our software. They contribute to the Sakai projects by providing feedback to developers in the form of bug reports and feature suggestions. Users participate in the Sakai community by helping other users on mailing lists and user support forums. The passive users are also known as lurkers.
Developer
From Apache: A Developer is a user who contributes to a project in the form of code or documentation. They take extra steps to participate in a project, are active on the developer mailing list, participate in discussions, provide patches, documentation, suggestions, and criticism. Developers are also known as contributors.
Committer
From Apache: A Committer is a developer that was given write access to the code repository and has a signed Contributor License Agreement (CLA) on file. Not needing to depend on other people for the patches, they are actually making short-term decisions for the project. The PMC can (even tacitly) agree and approve it into permanency, or they can reject it. Remember that the PMC makes the decisions, not the individual people.
PMC Member
From Apache: PMC member is a developer or a committer that was elected to the PMC due to merit for the evolution of the project and demonstration of commitment. They have write access to the code repository, the right to vote for the project-related decisions and the right to propose an active user for committership. The PMC as a whole is the entity that controls the project, nobody else.
...
Many projects will dispense with any differentiation between committer and PMC members and simply define the committers as the PMC. For a small project with 3-4 committers, there is no reason to get too wound up in process and procedure. The distinction is still useful to reinforce the notion that the decision making within a Software Project is delegated to those who have demonstrated long-term involvement and are clearly dedicated to the project in the long term.
Becoming a Committer
The initial committer list and PMC is generally comprised of the people who developed the software in the first place. Once the initial committer list is in place, the committer lists and PMC maintain their own membership. Neither the Sakai Foundation Board nor the Sakai Staff have any influence in the commit list of a particular project.
The most general path to becoming a committer and PMC member in a project is that a person is a valuable addition to the team. In many projects there is a great deal of work to be done and so new people who are willing to commit to the project and help are generally welcomed with open arms.
...
Each PMC must establish and publish the rules for applying for membership. Looking at Apache PMC charters, there are three common patterns that Apache PMC's use: (1) Anyone can self-nominate themselves to the PMC and the PMC votes with a +1,0,-1 style, (2) only PMC members can nominate a new committer - then the PMC votes with a +1,0,-1 style, or (3) PMC membership is invitation only - the PMC monitors users and developers working on the project and contacts potential new committers as the PMC sees fit. There is no one right way to maintain the list - these examples serve to emphasize the point that the PMC gets to determine the rules of its membership.
Being a Committer
Apache references: http://www.apache.org/dev/committers.html
...
Some projects use the concept of an emeritus committer status. This is typically suitable for those committers who can no longer give the time they feel is required.
Joining a Project
As a community source project, Sakai depends on new people and resources to join our effort. This can appear to be a daunting task to new arrival to the Sakai project. When in doubt, a good place to start is the Sakai Project Coordinator. The Project Coordinator will generally have a starting point and single point of contact for every activity within Sakai.
...
This section lists some common scenarios that you may find useful. An important part of this is to be patient- many PMC's are very busy and often have a full plate - especially around Sakai releases. You must remember that the purpose in volunteering is to "help" and "assist" the PMC and in general improve things. At some level, the PMC gets do decide if you (the volunteer) have the skills, talent, and commitment to fit into their activity.
Long Term General Commitment to a Project
In this situation, an individual or organization wants to become part of the commit team and PMC for a particular project. An example of this might be a person who simply wants to join the Wiki team and help in any way that is necessary. This is generally a long process. The new volunteer should be willing to work on any aspect of the project that needs work. Often, bug fixing, documentation, building units tests, investigating new possibilities for the project, writing designs, evaluating patches, and answering questions on mailing lists, are all example "first activities" that the volunteer might be assigned. At the same time, in exchange for the new volunteer helping with these important (but not necessarily exciting) tasks, the new volunteer should expect that the existing committer team and PMC should be very active mentors and help the new member of the project team move to a level of competence as quickly as possible.
Now this pattern is not set in stone - it is just important to understand that both the new volunteer and the existing committers will likely have to invest some energy in developing the new addition to the team. Hopefully the investment will pay off as more talent is available to the project in the long term and the team is more resilient to the loss of senior leadership over time.
A Volunteer with a Long-Term Broad Agenda
Sometimes a volunteer will be coming to the project with a long-term agenda - sometimes this agenda will cross project boundaries. An example might be a person who wants to work on Internationalization across the whole Sakai Distribution. The challenge for this type of volunteer is that the person will be working with many PMC's and those PMC's may or may not have time to mentor the person as the volunteer "passes through their project".
...
Historically, as long as these volunteers with a long-term board agenda are patient, they can usually be quite successfull with the PMC's and after a while, PMCs will likely give the person commit access as long as the person agrees to check with the PMC before starting any significant work.
A Volunteer with a Short-Term Focused Agenda
Usually this type of volunteer wants some very specific thing done in a project but is not willing to make a long-term commitment to a project (i.e. has not intent on joining the PMC for the project). The most common situation is the need for a new feature, requirement or even a major bug fix. Again, the volunteer cannot make demands of the PMC just because they have volunteered - they must work with the PMC and align their work.
There are three sub-scenarios here depending on the size of the work being considered and the readiness of the PMC to engage in that activity. The first step is to contact the leader for the project and discuss the situation.
Small Change
Sometimes a change is small enough and naturally fits into the work of a current committer in the project. In this case, an existing committer in the project and do the work can simply do the work in the normal course of development. Usually the effort will be tracked through JIRA until it is completed.
Short Term Mentor
Sometimes a change requires too much work to just have an existing committer do the work. An ideal situation is for one of the existing committers to mentor the volunteer and guide the volunteer as the new work is developed. This may entail helping with design documents, helping the volunteer get their design reviewed, give suggestions as to the best approach to implementation, and mentoring the volunteer during the development process.
Once the code is developed, the mentor can review, test, and then commit the contribution from the volunteer.
The Current Committers are Simply too Busy
At times, the current committers will be simply too busy to provide the necessary management for the volunteer during the time frame that the volunteer wants to perform the work. This is not an ideal situation but one that may be all too common during the early years of Sakai where we have a few very busy committers.
...
The modifications may need to be made available as a patch if there are members of the community that need the feature before it is integrated by the project committers. These patches may need to be ported across releases. Hopefully in time the project committers will find time to integrate the patches into the released version of their project.
Understanding the Nature of Volunteer Resources
Other than the Sakai Foundation staff members, everyone in the Sakai Community is a volunteer. While they may be paid to work for some company or university that is involved with Sakai, strictly speaking the Sakai Foundation must treat individuals as volunteers.
Respecting the volunteer nature of the community is why there is very loose coupling between the projects and the Sakai Foundation. The Sakai Foundation can communicate, suggest, guide, produce requirement documents, identify areas that are high priority, do roadmaps, and even drop a software element from a distribution if it is not technically ready. But through all of this the Foundation must respect that it cannot give "orders" to the volunteers that make up the projects.
If you want to affect a project - Join it and Contribute
Many projects will be very busy and working very hard on a long series of tasks that stretch out for possibly many years. The members of a PMC are the ones who best know the complexities of the work laid out in front of them. It is a mistake to believe that the Sakai Foundation staff or even members of the community will naturally know what is best for any given project.
The only way to truly have impact in a project is to take the time and find a way to contribute to the project. Simply standing back and telling a project what is the best way for it to do its work, or criticizing the project is generally a poor way to have impact.
The Right to Ignore
A natural effect of working in the open is that there will often be far more users/lurkers than PMC members. The PMC uses the mailing list to work through issues and make their decisions in the open.
...
If a user or developer persists in pursuing a conversation to the point that the discussion is disruptive to the operation of the PMC, that user will be asked to move their discussion somewhere other than the PMC's mailing list. In Sakai we have a list called OpenForum where any topic can be debated and discussed as long as folks find it interesting. Project lists are there to allow the PMC to do their work in a public way.
Lack of Need to Always Agree
The Sakai Foundation strives to create an environment where decisions are made by those best placed to make them, in the open, by those "on the ground" and contributing to the solution, and with as much relevant consensus as possible. The Sakai Foundation also works to create an environment where disagreement can flourish without being crippling, where alternative solutions are supported, and where, in the most cases possible, we can "agree to disagree" and the work can go forward.
Our community is rooted in intellectually and technically innovating organizations that are very diverse along a very large number of dimensions. The Sakai software, its community and its goals attract individuals that work in rapidly changing environments and are working hard to accelerate that innovation and change. In many cases the creative opportunities that current design methods, software tools and development environments provide allow for a wide range of approaches to solving particular needs. In as many places as possible the Sakai way is to support alternative approaches which can be locally realized to best effect. It tries to find ways where "we don't need to agree" on the detail, and multiple approaches can be taken in the projects doing the work.
Conflict Resolution
If the Apache experience is any indication, these procedures, approaches and values will avoid conflict. Given that projects and the community are charged with working together as mutually respecting peers, hopefully mutually agreeable solutions will be worked out at the lowest possible level and not require any involvement "from above". Hopefully all projects take as a founding principle to work in the best interest of the community and not in the personal interest of the PMC members.
...