Note: This is a draft document and may change significantly before being finalized!

The following guidelines describe how SproutCore is maintained and improved through the combined efforts of a community of collaborators working together to create the best and most fully featured client-side JavaScript development framework.

If you are interested in contributing to the growth and development of SproutCore in even a small way, please take a moment to familiarize yourself with this guide. You will find that there are different roles available, such that one should suit your desired involvement.

This is a living document and will be re-evaluated and updated as it is put to use. If you know of any way that we can improve our processes, please use sproutcore-dev@googlegroups.com for suggestions.

The current list of collaborators is maintained here.

From a developmental viewpoint, SproutCore is not just a single JavaScript framework, but a collection of projects, the most notable being: sproutcore/sproutcore, the aforementioned JavaScript framework; sproutcore/abbot, the build tools and development server and sproutcore/sproutguides, the user guides.

There are also several other smaller projects that make up the SproutCore ecosystem, such as the TextMate bundle, sproutcore/sproutcore-tmbundle and therefore, there are many projects that could use your expert skills. As well, if you wish to create a new project for the benefit of the community, there is also a process for that described below.

To serve both the interests of engaging a vibrant community of developers and of maintaining the highest quality product, we will follow a tiered contribution structure for developers. This structure is based heavily on the WebKit policies, which have been successful for the WebKit Open Source project. For our purposes, we define four different roles of developers: Contributors, Committers, Reviewers and Project Owners; and one administrative role: Administrators.

Any person may contribute to SproutCore by submitting pull requests on github. The guidelines for getting a pull request accepted are here: Code Contribution Guidelines.

As a Contributor, your job is to work with Reviewers and Committers to get your code merged into the main repository. To do this, start by submitting a pull request on github, notifying one or more of the current Reviewers listed on the Contributors Wiki Page.

Once you submit a pull request, at some point, a Reviewer will take a look at your patch and choose to accept it or not accept it. If the request is not accepted, the Reviewer will try their best to explain the reasoning and will offer some guidance as to what would make the request acceptable. You can then make any necessary changes and ask the Reviewer to look at it again.

Once the request is accepted by a Reviewer, the Reviewer may merge the request immediately or they may simply note "Accepted" in the comments. This is common, for example, if the request is complicated to merge and the Reviewer doesn't have the time. Once a request has been accepted by a Reviewer, any other Reviewer or Committer can merge your patch for you. Just find someone from the list and approach them or ask on IRC or the mailing list.

If you submit a pull request and no one gets back to you immediately, feel free to ping a Reviewer or Committer (once your patch is accepted) to get the request pulled in. People get busy with their day jobs sometimes. The project has multiple Reviewers and Committers to ensure someone is always available to look at your patch.

Committers are Contributors who have commit access to one or more of the repositories under the SproutCore project. They must work within their own branch of the project and submit changes as pull requests. In this sense, being a Committer is not much different than being a Contributor, except that Committers may directly merge other pull requests as well as their own changes once they have been approved by a Reviewer and more importantly, being a Committer means a stronger relationship with the project's Reviewers and Owners, which will help the Committer write easily acceptable code.

Responsibilities

• Committers should attempt to resolve two github issues each week

Acceptance Conditions

Each Project Owner is responsible for determining who is given commit access to his or her project; however, the suggested guidelines are that the person:

• Is already a Contributor.
• Has had at least five to ten pull requests accepted to the project.
• Is recommended by a Reviewer.

The Project Owner can appoint as many Committers as he or she feels is necessary to meet the demands of the individual project and can remove inactive Committers at any time.

How To Become a Committer

Once you have met the acceptance conditions above, find a Reviewer who will sponsor you. Anyone can become a committer as long as they have approval from the Project Owner and at least one other Reviewer.

Reviewers are Committers who review and approve or reject pull requests. While they should also work within their own branch and use pull requests to gather feedback on their own changes, they are allowed to commit directly to master when the situation calls for it. This would include minor code tidying and critical bug fixes. But primarily, they are charged with reviewing requests to ensure that the new code meets the Code Contribution Guidelines and meets the goals of the project.

Responsibilities

• Reviewers should attempt to resolve three github issues each week
• Reviewers should attempt to accept/reject two github pull requests each week

Acceptance Conditions

Again, each Project Owner is responsible for recruiting appropriate Reviewers. A suggested guideline is that the person:

• Is already a Committer.
• Has had at least 30 to 40 pull requests accepted to the project.
• Has demonstrated a thorough understanding of the architecture of the project.
• Has shown a long-term commitment to documentation and community assistance.
• Has demonstrated excellent judgment and collaboration skills.

The Project Owner can appoint as many Reviewers as he or she feels is necessary to meet the demands of the individual project and can remove inactive Reviewers at any time.

How To Become A Reviewer

Reviewers are the people we entrust with the future of the repository. It carries a great deal of responsibility to carefully collaborate with other reviewers to maintain code quality and future directions. You will be expected to regularly participate in mailing list discussions and to respond to contributors who will be asking you to review their patches.

If you are ready for this commitment and you meet the acceptance criteria above, then just find another reviewer on the project and ask them to sponsor you. They will need to ask the other reviewers to vote. Approval from a majority of reviewers and the Project Owner is all that is required.

We put up a blog post anytime a new Reviewer is added.

Each repository within SproutCore has a Project Owner in charge of guiding the direction of that individual project, and responsible for selecting Committers and Reviewers who get commit access to the repository. Most projects will have only one Project Owner, but sufficiently large projects may have two or more owners.

If you have created a project that you feel should be part of SproutCore, you will need to get a Project Owner to sponsor your project. If two-thirds of the Project Owners vote for including your project, it will be added and you will become a Project Owner of that project.

Responsibilities

• Project Owners should attempt to spend at least one hour per week on documentation: jsdocs, guides and blog posts.
• Project Owners should create a list of clearly defined tasks that enact their strategies and assign these tasks to Reviewers and Committers.
• Project Owners should work closely with an Administrator to check on the status of tasks and re-assign tasks as needed, understanding that volunteers are not always able to contribute regularly.

Acceptance Conditions

The core team of Project Owners is responsible for recruiting new Project Owners. A suggested guideline is that the person be recommended by an existing Project Owner and receive the support of two-thirds of all of the Project Owners.

How To Become A Project Owner

Project owners are usually the person who first creates and project and then asks a Project Owner on another project to sponsor you. Once they get the 2/3 vote required, your repository will be added to the SproutCore Github account and you will be listed as the Project Owner. You can then nominate any reviewers and committers as needed to bootstrap the project.

If you no longer feel you can carry out the responsibilities as a Project Owner, you should nominate a replacement which must be approved by the other Project Owners and then you can step down.

We put up a blog post anytime a new Project Owner or Project is added.

It should be fair to say that every successful project included people committed to the process itself. As such, we have defined the Administrator role; responsible for the maintenance of the open source collaborative effort. The number of projects a person administers is unimportant, as long as each project has at least one person filling that role. The Administrators' primary job is as project manager: scheduling meetings, gathering proposals, recording minutes and bringing issues to the attention of the various Project Owners. Some Administrators also have administrative access to the various assets that have been acquired under the SproutCore name over the years, such as the github account and the sproutcore.com web hosting and domain hosting accounts.

Responsibilities

• To compile a list of proposals for discussion at the Project Owner meetings.
• To take minutes of all meetings and circulate the minutes.
• To review the minutes from the previous meeting at the Project Owner meetings.
• To administer the SproutCore assets

Acceptance Conditions

Any Project Owner or Reviewer may volunteer to act as Administrator; however, only the most senior Administrators will also get access to the SproutCore assets.

How To Become an Administrator

To become an administrator for a project, you just need the support of the Project Owner. Contact the owner to volunteer.

Please note that SproutCore is not a "hobby" framework. That is, SproutCore is a well-tested, mature, full-stack framework that companies choose to create fast, stable and multi-browser/multi-device web applications that their livelihoods depend upon. Of course, hobbyists can also fully utilize SproutCore for their own projects, but as a community effort, what this implies is that the bar to entry for contributions has been steadily increasing.

If the reviewers are doing their job properly, you may find that contributing is a difficult task at first, because you have to consider the many consequences for each change. If this is the case, please take it as an opportunity to grow your skills and please do keep trying. To make it easier to contribute, the rules that contributions must follow are described in the Code Contribution Guidelines. As well, we will be working to split the larger projects into smaller independent projects that require less comprehensive understanding to work on.

Thank you so much for your efforts, we look forward to having you on the team!