...
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.
New Projects
The one sure-fire way to get commit status is to start a new project. As the creator of a new project you are the PMC and you get to make all of the important decisions about your project going forward.
Sakai encourages new projects, as this is the source of the innovation necessary to produce the rich product desired by the Sakai community. The Sakai "contrib" area is Sakai's version of SourceForge. There are four basic phases in a new project's lifecycle. Not all projects will progress through all four phases: (1) completely independent contrib. project, (2) community adoption, (3) provisional status, and (4) a full component of the Sakai distribution.
Independent Contributed Project
This is a project that is using Sakai's SVN contrib. to support a Sakai-related development activity. It is relatively simple to get a new contrib. space created - contacting the Project Coordinator with a short summary of who will be the single point of contact (the initial lead committer) and what activity will be done in the space is all that is needed.
During this initial phase, there is no need for contributor agreements or precise licensing requirements. But if this project is intended for ultimate distribution as part of Sakai the effort would be well-served to start out requiring Sakai Contributor Agreements and develop the code following all of the Sakai Foundation Licensing Practices. It is generally easier to start with this discipline at the beginning rather than trying to get this sorted out as the project is trying to move into Provisional or Release status.
The three common uses of contrib. are to: (1) develop a tool or component that will grow and mature for the ultimate Sakai distribution, (2) store useful information in a place that the community can look and reuse - a common example here is for a university to store their Sakai providers in a contrib. area because there is community interest in their local work, and (3) advance some completely crazy experimental Sakai work that a few people want to keep in one place so that they can work collectively on the effort and possibly recruit new members of the community to join them in their quest.
The Sakai Project Coordinator monitors and reports on these activities. If after a time, a contrib project seems to have no value and/or no activity, the effort may be archived and mothballed.
Community Adoption
Once a project reaches a maturity and quality level that the team feels shows it is ready to release, the team can release the project as a "drop in" to an existing Sakai distribution. The team can produce install documentation for their product and work with community members who choose to use the new product.
Community adoption is an important phase for any new project to go through. Generally no new project will be accepted into the Sakai release until it has demonstrated that it works effectively and meets user needs at a number of community sites. It is also important that when members of the community other than the initial developers can install and run the product reliably in production, it gives some assurance that the software will not be a problem when it is made part of the Sakai distribution.
Provisional Status
Once a project has been successfully adopted and used by some subset of the community, it can be considered for provisional inclusion in a Sakai distribution. A provisional capability in Sakai is one that is included in the distribution but "turned off" by default.
During the release and QA process, it is up to the respective Project team to do QA on the provisional project. The Sakai Foundation QA effort focuses their effort on the components that are fully supported in the distribution. The Foundation QA effort, however, does test to see if the introduction of the provisional project destabilizes the other elements of the distribution in any way.
There is a series of technical criteria a project meets to be considered as provisional. These are described in detail in a separate document. The high level overview is that a provisional tool is technically and legally part of the Sakai distribution - this means that things like licensing and contributor agreements must be 100% completed and 100% acceptable to the Sakai Foundation even before a technical analysis of the project is undertaken. This suggests that projects intending to be part of the distribution should start dealing with contribution agreements and licensing issues very early in the project.
The project team for a provisional tool must be willing to participate in and support the Sakai release process, QA effort, bugs tracking, etc.
Sakai's Provisional Status is somewhat similar to Apache's Incubator status in that they both describe "projects in waiting" or "on probation". But again, the detail here is left to a separate document.
Apache Reference: http://www.apache.org/foundation/how-it-works.html#incubator
Full Component of the Sakai Distribution
Once a tool has been a provisional tool and appears to work well within the Sakai distribution, it can be promoted to being part of the official distribution.
There is a set of technical and other requirements that a tool must meet to become part of the Sakai distribution. The provisional distribution requirements "bar" is set somewhat low to encourage new tools to make it in as provisional tools. However, the "bar" is higher for full components.
Additional elements required for promotion to full distribution status include: test plans, accessibility audit, internationalization support, import/export support, and others. The high level summary is that to be a Full Component in a Sakai distribution the new element must function like the rest of the Sakai tools and be fully and seamlessly integrated into Sakai.
Guiding Principles
There are a number of guiding principles that underlie this document. This section attempts to capture the nature of these concepts.
...
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.
Document History
All major changes should be recorded in the following history table:
...
Version
...
Date
...
Contributors
...
Description of Change
...
1.5
...
...
Charles Severance and Joseph Hardin
...
...
1.6
...
4/6/06
...
Charles Severance and Joseph Hardin
...
...
...
4/14/06
...
Mark Norton
...
.