Contribution and Management Policies
From Portico
This document describes the project management procedures for Portico.
Contents |
[edit] Definition of Terms
The following is a list of terms used throughout this document.
- Arbiter: A role that rotates among the members of the management group. The Arbiter is responsible for managing the voting process and acting as the official "voice" of the project on management issue
- Commit Access: The permission to edit, update or remove any data in the project version control system (generally program code).
- Contributor: A member of the community who offers work to the project. For example, if someone fixes a bug, they may contribute that fix back to the project.
- Core Developer: Each project has a group of developers who are responsible for the bulk of the development, maintenance and support. Further, a Core Developer is someone who has been granted commit access.
- Management Group: The group of core developers.
- Patch: Set of code that changes the behaviour of the project (fixes a bug, introduces new functionality etc...).
- Version Control System: A repository where the set of existing code and related artefacts (such as documentation) resides.
[edit] Purpose
The procedures outlined in this document are designed to cover the management of the Portico open source project. They outline how issues and questions about direction and project management are to be addressed, what types of issues should be managed under this process and who is involved in making those decisions.
The basic process here represents a combination of open source "best practice" as drawn from investigation into the management of open source projects under the Apache Software Foundation, the Eclipse Foundation and the Django Project.
[edit] Community Structure
The diagram below outlines the basic structure of communication and responsibility within a typical open source community.
The Management Group are responsible for updating and administering the project source, direction and policies. This is done in consultation with any number of other interested parties who may contribute code, support and discussion. The Community is defined as the entire group working together.
[edit] The Management Group
The primary governing body in an open source project is the group of core developers responsible for the creation, maintenance and support of the project. Members of this group are identified as the individuals with "commit access" to the version control system.
[edit] Membership
Membership to this group is purposefully kept small and inclusion is based entirely on merit. Membership of this group is given to individuals, free from any commercial or other group affiliation that person may have. Offers of membership are only extended to those individuals who have a significant history of contribution to the project and a demonstrated commitment to the community through development and support activities (as represented by activity on mailing lists and forums).
[edit] Rights of a Member
Recognising the contributions of the group, "commit access" to the project includes with it the following implicit rights:
- The right to alter the code and artefacts of the project
- The right to one (1) vote on any resolutions considered by the management group
[edit] Becoming a Member
When a member of the management group believes a contributor has met the criteria outlined above, they can propose a resolution to offer membership to that individual. This proposal must include relevant details of the foundation on which the proposal is being made.
All members of the current group must vote on the resolution. To keep the size of the group small and manageable, the vote must be unanimous if the contributor is to be admitted. In the absence of a unanimous decision, no offer will be made.
[edit] Resigning or Removing a Member
From time to time, for any number of reasons, people will need to be removed from the group.
Any member may relinquish their position at any time. In the event that a member wishes to relinquish their position, no vote is needed and the membership of the group is adjusted accordingly (commit access will be removed, thus signalling the change).
In the event that a member may need to be removed from the group (perhaps due to sustained inactivity, continued conflict or some other reason), any member of the group can call for a resolution to remove the individual in question. This call must be accompanied by a clear outline of the grounds on which it is based. A vote on this resolution is taken, and should the result be unanimous, the membership of the group is revised appropriately. The member is question is excluded from the vote.
Given the important nature of this group, and the restrictions on becoming a member in the first place, if the decision is not unanimous, no member shall be removed.
[edit] Presenting and Handling Resolutions
The responsibilities of the management group cover a large number of areas. Issues that the group must consider can be broadly grouped as follows:
- Small Technical Issues: The fixing of small bugs or the incorporation of small new features. This also covers the incorporation of appropriately sized user contributions and patches into the project code.
- Medium/Major Technical Issues: Any activity that involves significant alterations to the current codebase of the project. Broadly speaking, any changes that introduce new major features, or that require considerable development and/or internal refactoring would fall into this category (be they as a result of feature implementation, bug fix or architectural refactoring). (RESOLUTION REQUIRED)
- Management Issues: These are non-technical issues relating to the management of the project. For example, the introduction or alteration of a management entity or process would fall into this category. (RESOLUTION REQUIRED)
Any management group member can resolve small technical issues at any point in time. To remove as much managerial burden from this group as possible, it is not necessary for any member to seek a resolution on the inclusion of these changes. Membership to the management group is based on demonstrated competency through contributions. As such, determination of the whether or not the change is large enough to need resolution is left to the member's best judgement.
Technical issues that necessitate alterations of a medium-to-large nature require consultation and resolution. The exact criteria that distinguish a medium-to-large change are somewhat fluid and situation dependant. Broadly speaking, any changes that introduce new major features, or that require considerable development and/or internal refactoring would fall into this category.
The final category relates to non-technical issues regarding the management of the project. This includes the introduction of new processes, the alteration or removal of existing processes and the creation of new management entities. Membership management is an example of this type of issue.
[edit] Presenting Resolutions
For any situation in which a resolution is required, it must first be presented to the management group. If the submission originates within the community, but arrives without the endorsement of a management group member, it does not have to be considered for resolution. This condition is provided to stop the management group being overrun by community proposals that appear without any consultation.
If the submission is presented to the management group by a member, or with the explicit endorsement of a member, a resolution is required.
[edit] Coming to a Resolution
Resolution of an issue is controlled by a direct vote. To facilitate the timely resolution of issues, a vote may be active for no longer than ten (10) days. If a member has not voted at that stage, they are deemed to have abstained. In the case of decisions that require unanimous results, an absent member is not considered, and a unanimous decision may be achieved without them. To remain transparent, the recording of votes and the results must be publicly accessible.
Each management group member is given a single vote. The set of valid responses is:
- +1: The member strongly supports the change
- +0.5: The member has no strong feelings, but generally support the change
- 0: The member abstains from the vote, or has no opinion
- -0.5: The member has no strong feelings, but generally rejects the change
- -1: The member strongly rejects the change
The result of the vote is determined through a simple summation of the values:
- Result is GREATER than 0: If the result is greater than 0, the resolution is accepted and the action described within is endorsed
- Result is LESS than 0: If the result is less than 0, the resolution is rejected and the action described within is not to occur
- Result is EXACTLY 0: If the result is exactly 0, the group is first given the opportunity to "revote." If no member wishes to amend their vote, the arbiter is given the final decision (see below)
[edit] The Arbiter
In the event that the sum of the results is 0, each member of the group is given the opportunity to revote. If, on the second vote, the result is still 0, the final decision is left solely to the "Arbiter".
This is a rotating position that is passed from member-to-member (round robin). The term of the role lasts until the next release of the project (one release cycle). The ordering of members is based on the date on which they first became a member. If a group member is not willing to act as the Arbiter at a particular point in time, the title will flow to the next willing member.
The role of the Arbiter is three-fold. Firstly, it is the responsibility of the Arbiter to conduct the voting process. Secondly, it is their responsibility to break a tied vote. Finally, the Arbiter acts as the formal voice of the project. While all management group members speak on behalf of the project, it is the Arbiter that is recognised as the official voice of the project.
The removal of the Arbiter from their role falls under the same process as the removal of a management group member.
[edit] Discipline
In situations where a member of the community or the management group is causing continual problems, disciplinary action may need to be taken. The procedure for these situations is much like that for handling issues of a technical concern. For problems of a minor nature, it is expected that any member of the management team or community would taken an appropriate action (eg public or private warning).
For ongoing problems or issues of a more serious nature, disciplinary issues are treated like any other managerial issue, and a resolution is needed. Penalties may include the removal of privileges (such as commit access), or any other measure deemed appropriate by the management group. The Arbiter is responsible for enforcing the resulting decision.
[edit] Restricted Committer
In an effort to provide some support for Portico plugin developers and a place where they can carry on their work, the Portico Project also introduces the notion of "restricted committer". Following approval from the Management Group by vote, a person can be allocated some space on the subversion server which they can use for their development efforts.
[edit] Restricted Committer Conditions
However, this would means that the user requires commit access to the server, which typically would designate them as being part of the management group. To solve this problem, people granted "restricted commit access" are subject to the following conditions:
- person requesting access must have some code already developed to show some commitment to the exercise
- commit access is allowed only to the branch created for the development (not allowed to directly commit code to the Portico trunk and branches)
- no rights with regard to project management (voting, etc...). None of the rights given to the Management Group flow to restricted committers)
- access is for a limited term (3 months initially, reviewed and extended after that)
[edit] Enforcement
The Portico Project is currently hosted on Sourceforge. Unfortunately, Sourceforge doesn't support subversion permissions settings. Thus, the restrictions outlined above are enforced by policy, rather than force. If a restricted committer breaches these conditions, their commit access will be IMMEDIATELY revoked and may only be restored if the Management Group votes to do so.