The Angel Community functions as an open source Project, with a set of rules and leaders elected and approved from within the participants of the project. This page serves as a summary of the community governance. The following serve as the official sources for Angel Governance.
Angel Technical Charter (ATC) which defines the mission, scope, and key provisions of the Project.
Angel Technical Community Document (ATCD) which defines the essential business operations of the Project.
TSC Chair/Project Technical Leader Elections
To make the governance simple, the TSC Chair of Angel is also the Project Technical Leader. Every year the Angel Community is required to vote on the technical/TSC leadership for the Angel Project. There are several different areas where voting is relevant.
Project Technical Leader Elections
Election Coordinator: Fitz Wang (As of Nov. 2019)
Who is eligible to Run: TSC members of the Project of record (as per the wiki page) effective the date the nomination process starts. Candidates must self nominate.
Who is eligible to Vote: TSC members of the Project of record (as per the wiki page) effective the date the nomination process starts AND as controlled within the context of the Angel Technical Community Document.
Who will run the election Process: An Election Coordinator will be designated from volunteers within the Angel Community. The Election Coordinator should be a non-running member.
Self Nomination Phase
When appropriate a call for nominations will be sent by the Election Coordinator to the appropriate project mail list. Individuals interested in running for the Project Technical Leader position must reply-all to that email with their intention to run. It is recommended that candidates include a biography and statement of intent on why they would be a good person to hold this position. The nomination phase begins with the receipt of the announcement (as verified by checking the appropriate mail list within the Angel Groups.io). The nomination phase ends four (4) full business days (or other agreed upon timeframe) after the announcement in the same time zone the poll was initiated from.
All project committers (as indicated above) will receive an invitation to vote. The Election Coordinator will call a meeting for poll, the individual receiving the highest number of votes from all votes cast shall be declared the winner. The Election Coordinator will then send an email to the sub-committee mail list and to the TSC mail list.
As specified in the Technical Charter, a Contributor is anyone in the technical community that contributes code, documentation, or other technical artifacts to the Project. Contributors always have a voice and are welcome to provide thoughts and insights in any technical discussion within the project as well as assist in direct use and testing of the project artifacts. Examples of participation include but are not limited to:• Providing input/responses on the email list
• Contributing a bug fix via Gerrit
• Contributing code for a new feature via Gerrit
• Writing test cases or documentation
• Reviewing commits in Gerrit
• Integration/deployment testing of merged commits
• Triaging failed builds/deployments and runtime use cases
• Jira/Confluence authoring
• Contributing to weekly meetings and getting involved in assigned tasks
As specified in the Technical Charter, Committers are Contributors who have earned the ability to merge contributions (“commit”) source code, documentation or other technical artifacts in a project’s repository. A Contributor may become a Committer by a majority approval of the existing Committers. A Committer may be removed by a majority approval of the other Active Committers. Unless otherwise defined in TSC policies published on the Angel Web Site, “Active Committers” are Committers who have merged contributions in at least two separate instances over the last six months.
Since there may be multiple repositories per project, Committer rights are per repository. Being a Committer on one repository in a project does not necessarily or automatically grant that individual Committer rights on all the repositories in the same project. Likewise, having Committer rights in a project does not automatically grant that individual Committer rights in other projects.
Committers are the decision makers for a project – design, code, patches, and releases. Typical characteristics of a Committer include but are not limited to:
- Deep expertise in the code base over which they are Committers
- Time dedicated to reviewing code contributions made by other Contributors
- Demonstration of good judgment and mentoring of others in the gerrit process
- Knowledge and understanding of the overall development activities occurring within the project and its components; this is important so that the review of new code is taken in the context of the overall development for the project
- Knowledge and understanding of other, interdependent projects within the platform and how contributions to this project affect work being done elsewhere by others
The Committers on a project review each code contribution made by the Contributors and other Committers on the project. Often, a Committer will need to enter into a dialog with a Contributor to have them make changes to the contribution to better fit the functional, structural makeup, or style of the existing code base. It is preferable to have at least 2 Committers show approval (with a +1) for a contribution before it is accepted into the repository. Please note that it is very common for individuals to be a Committer on one project and a Contributor on another. However, there is nothing stopping an individual from being a Committer on multiple projects and repositories.
Committers are the best available individuals and usually work full-time on projects and components in active development.
In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project is encouraged to taking on at least two Committers from different companies (subject to meritocracy).