Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
These pages are aimed at Alfresco contributors. An Alfresco contributor is any person who wishes to contribute to the projects hosted by Alfresco. There is a process to becoming an Alfresco contributor, as it is in everyone's interest that quality and processes are followed.
Once an Alfresco contributor, you will have full commit rights to the 'contrib' area of the Alfresco distribution. This area will be managed and controlled by the community of contributors, which will include Alfresco employees, on the basis of voting. This means that the contributor community has full autonomy on these projects.
There are mail-lists for the contributors, including project-specific lists.
Steps to become an Alfresco Contributor
To become an Alfresco contributor, you will need to be voted in by the existing members of the contributor community. You will need to be able to demonstrate your technical ability, such as by having a Forge project or other examples of your work for the contributor community to consider. A contributor does not need to be a Java developer, as the projects will include documentation, language packs, scripts and models. If you would like to become an Alfresco contributor, send an email to XXXXX.
Steps to Create a New Project
Once a contributor you will be able to propose new projects. You will need to get approval from the contributor community for the new project, so you will need to create a mission statement that describes the goals, approaches and mile-stones that can be distributed for voting. You will also need to identify the lead contributors for the project. The voting will follow the same process and rules as all voting within the Alfresco contributor community (see XXXX).
Once a project has been allowed, a top level directory will be created in the 'contrib' area along with a standard set of mail-lists for that project.
Participating in a Project
As a contributor, you have commit rights to the whole 'contrib' area, but it is expected that anyone wishing to make changes to code within a project communicates with the project lead before making them. This is both good manners and a way to avoid conflicting or duplicate work.
Project Leads
The Alfresco contributor community uses Project Leads as a way of providing some project-specific control and destiny. All projects within the 'contrib' area will have at least one project lead. The role of a project lead is to guide the development of the project, but not to dictate its development.
Voting Process and Rules
There are a number of formal stages of agreement within the Alfresco contributor community. All of these use the same voting process and rules to make decisions. There is a single vote for each contributor and follows the general principle of majority rule.
What this means is that a vote is usually considered passed when there are more positive votes than negative votes. However, there are a few exceptions, such as when a negative vote is considered a veto (see below).
Voting will follow the Apache style notation, examples of which are:
- +0: 'I don't feel strongly about it, but I'm okey with this.'
- -0: 'I won't get in the way, but I'd rather we didn't do this.'
- -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.'
- ++1: 'Wow! I like this! Let's do it!'
- -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.'
- +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.'
Veto
A project lead may veto a code change proposal, but the veto must be accompanied by a technical justification. Negative votes from other contributors within a project are not considered as vetos, as it is expected that the project lead is best placed to consider whether a negative point justifies them raising a veto. A veto may be raised by a project lead even if they have already voted positively.
Community
