Sakai Project Team Organization 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.

Many of the patterns in this document (and even some of the text) are derived from Apache documents (http://www.apache.org/foundation/how-it-works.html). Readers of this document are encouraged to read and review the Apache procedures to have a better understanding of the underlying principles that govern this document.

In terms of software development approach, Apache and Sakai overlap in many basic ways. In the areas where Sakai and Apache overlap, the Apache ideas are adopted nearly verbatim. Sakai is different from Apache because Sakai integrates the large number of its sub-projects into integrated distributions. Few of the Sakai sub-projects are useful outside the context of a Sakai software distribution. Most are intended as components that are assembled together to produce the Sakai final product.

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.

Decisions and directions in Sakai are made by those who have demonstrated "merit" rather than those who are in a "position" or have a "title". The Sakai Foundation staff members described above have responsibility for the overall effectiveness of the project and will likely be very influential in Sakai's directions. But in all cases, they have no granted authority which overrides the authority of the PMC's. The Sakai Foundation staff must earn their "merit" like any other member of the Sakai Community.

From Apache: What is interesting to note is that the process scaled very well without creating friction, because unlike in other situations where power is a scarce and conservative resource, in the Apache group newcomers were seen as volunteers that wanted to help, rather than people that wanted to steal a position.

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.

From Apache: We endeavor to conduct as much discussion in public as possible. This encourages openness, provides a public record, and stimulates the broader community. However sometimes internal private mail lists are necessary. You must never divulge such information in public without the express permission of the list. Also never copy an email between private and public lists (no Cc). Such an event would go beyond the normal need for email etiquette and be a serious breach of confidence. It could have serious ramifications, cause unnecessary confusion and ill-informed discussion.

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.

Projects in Sakai have different granularity - some are quite large and have broad impact (like framework elements) while others are relatively isolated and only affect a simple application within Sakai (like rwiki).

No single project is "above" or "below" any other project. All projects are peers within Sakai and when one project has a requirement that can only be satisfied by some change in another project, the two projects must work together to come up with mutually agreeable solutions that meet the needs, timelines, and requirements that are mutually agreeable.

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.

Note: The primary reason to have a difference between the Committer and PMC member is to point out the fact that simply given write access to a Sakai Software Project does not bestow on that person the right to make final decisions for the code. People will get commit for many reasons - one example is someone who works across many projects on Configuration management, Accessibility, UI cleanup, or Internationalization. That person may technically have the ability to make changes everywhere in the code. However that person does not have the right to make significant design decisions or rewrite major portions of code without working with the PMC for the project that they are intending to modify.

The PMC is best thought of as the "senior committers" for a Sakai Software Project and hold complete responsibility for their project. If a committer who is not part of the PMC makes a change, the PMC may veto that change and back it out.

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.

One of the key aspects of the Sakai (and Apache) committer process is that it is intended to insure that the new committers will be a positive and somewhat long-term addition to the team. The process has a natural timeline as an individual moves through the user, developer, committer, and PMC member phases. Part of the purpose of this time factor is to insure that the person is indeed committed to the project for the long run. If a person simply needs to make a few changes in a project and then go back to some other project, then there is no need to grant committer status or include the user in the project's PMC.

The PMC makes its rules for membership, but this might be an example rule-of thumb: A PMC applicant should be willing to invest at least 1/3 of their time for 12 months on the particular software project in question. A PMC applicant should be willing to work on all aspects of the Software project including fixing bugs, applying other developer's patches, testing, and participating in the release process for the project.

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

What must I do first?

The very first thing you need to do is to complete and submit a Contributor License Agreement (CLA). The process for this is described in a separate document. (See ...)

What are the responsibilities of a Committer?

From Apache: As a Sakai volunteer, you have the right to set your own priorities and do the work that scratches your own itch. As a Committer, you have a responsibility to the community to help create a product that will outlive the interest of any particular volunteer (including yourself). This means, for example, that the code that you commit should be clear enough that others not involved in its current development will be able to maintain and extend it. It also means that you are responsible for helping to grow and maintain the health of the Sakai community.

Deciding on release plans and releases
A prime responsibility of the Committers is to decide when a branch of code is ready for release. A release is not to taken lightly; each release must uphold the Sakai tradition of quality. Each Project Management Committee formally authorizes the distribution of releases to the public.

Applying patches
In order to grow and maintain healthy communities, committers need to discuss, review and apply patches submitted by volunteers. The Committers are also responsible for the quality and IP clearance of the code that goes into Sakai Foundation repositories.

Helping users
Committers should monitor both the dev and user lists for the projects that they work on and (collectively) provide prompt and useful responses to questions from users.

Monitoring commits and issues
Committers should review commit email messages for their projects and point out anything that looks funny or that may bring in IP issues. Monitoring Jira for bugs or enhancement requests is also a responsibility of Committers.

Reviewing Designs and Code
There will naturally be proposals and designs for new ideas for a project which come from many sources and code which comes from many sources. These will need expert review and guidance from the current committers.

Note: this is an incomplete list and not authoritative.

Is there a set term for acting as a Committer? Will I have to be elected again?

From Apache: Merit never expires. If you become inactive for a time (usually six months or more) your account may be deactivated for security reasons. Most projects allow reactivation of committer status by application to the PMC.

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.

Each project has its own management committee (PMC) and so to join a group you must work with the PMC to become part of the group. Each PMC sets its own rules in this area - this section of the document contains some common guidance and general ideas that a PMC may choose to use as their procedures or a part of their procedures.

Generally a new member of the community has an idea of how much time investment they are willing to make, and perhaps even have a strong idea as to what they want to work on. Perhaps the motivation is due to a local imperative (i.e. the person's boss), or perhaps a grant-funded activity, or because the person participated in the Sakai Requirements process and felt so strongly about a requirement that they wanted to help implement the requirement. All of these are good reasons and all of these help Sakai move forward.

One of the most precious resources in Sakai is senior leadership and so we need to come up with procedures that make best use of this scarce resource. The concepts in this section try to respect the value of the existing PMC members.

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".

A person working on cross-cutting issues will need to be self-managed. The person will have to work with each PMC directly and fit their agenda into the agenda of each PMC to the satisfaction of the PMC. A key concept here is the volunteer cannot make demands on the PMC to alter the PMC's schedule and plans to meet the needs of the volunteer's timescale. It is incumbent on the volunteer to "fit in" with the PMC efforts. Volunteers should not expect the Sakai Foundation staff to "give orders to PMC's" so that the volunteer can make progress.

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 solution is for the volunteer to do the best they can looking at the code and making their own decisions and solving the problem as best they can with limited help/guidance from the PMC. There are architectural ways in Sakai to give this work the best chance of success. Before this effort is started without a mentor, the Sakai Chief Architect should be consulted to see if there are some recommended approaches that might make life easier when the modifications are brought back into the source tree.

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.

Simply joining a list or being a user does not give a person the right to "vote" or affect direction. This is done over time by becoming a committer, and eventually PMC member.

While open dialog, criticism, and brainstorming on the project list can be quite useful; the PMC usually has some task and work that needs to be done.

If a user/lurker jumps into a conversation and sends messages that are not on topic or not particularly useful, they should not be surprised if their message is simply ignored by the PMC members. If a user or developer wants to help, the best approach is to listen carefully for a while, understand the issues and then find a way to help.

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.

However, the Sakai Foundation Board does retain the ultimate ownership of, and responsibility for, these projects within Sakai. The Foundation chooses to grant this authority to the PMC's for each project with very few "strings attached" - but the Foundation does remain, ultimately, responsible for the successful operation of the projects.

If there is a conflict between two projects, or between a project and the community, the Sakai Foundation Board and Staff will primarily try to mediate the debate and get the parties to communicate better, then perhaps understand the nature of the conflict, and then perhaps help the parties to find a mutually agreeable solution.

If a project and PMC seems to have a pattern of not operating in the community's best interest, or has a history of unreasonable uncooperative behavior, the Foundation may step in and take explicit action. This action will likely take one of the following two forms.

The removal of the PMC Chair (Lead committer) or the complete removal of the entire PMC with the hope of reforming a PMC that will operate in the best interest of the Sakai community and Foundation.

"Demoting" the project from the Sakai distribution with the hope that a replacement project will grow to fill the space left by the removal of the project from the Sakai distribution.

These should be understood as drastic actions, only applicable to extreme cases, and taken only after it seems that every avenue to resolving the conflict has been tried. In the Apache experience, with well over 20 active projects, this type of drastic action happens less than once per year.