Clear and transparent governance is a key part of any open development project. It defines the rules of engagement within the community and describes what level of influence a community member can expect to have over a project. In addition, it enables members to decide their level of involvement with that community.

The community encourages loyalty rather than legalities. Members are free to take the code and create alternative projects as long as this is for the benefit of the community, rather than for a single individual or company.

Not everyone has a binding vote, keeping the decision making authority to those who share a common vision and who are willing to work towards that shared vision.

For each role listed below you may find more details in Structure and Roles  section.

Members

Anyone can become a member.

Users who continue to engage with the project and the community can become contributors.

Contributors

Community members who wish to take an active part in the community can become a contributor. All contributions are submitted as patches that are validated by committers or project maintainers.

Contributors engage with the project through forum, blog, projects, and mailing lists. There is no expectation of commitment, no specific skill requirements and no selection process.

Contributors can be nominated as committers as soon as they prove their attachment and willingness to help in reaching goals.

Committers

Committers are community members dedicated to the continuous development. Committer-ship allows contributors to easily carry on with project related activities by giving them direct access to project resources. That is, they can make changes directly to project outputs, without having to submit changes via patches.

Anyone can become a committer if they show willingness and ability to participate in the project as a team player.

Nominees may decline their appointment as a committer. This role allows people to contribute more easily.

Committership is a privilege, not a right. This is earned and can be removed in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.

A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become project maintainer, and thus part of the Technical Committee.

Technical committee

The technical committee consists of all project maintainers. Its main role is to set a vision and strategy for the community, as a whole, especially from the technical and business point of view, to decide upon matters that cannot reach a consensus among the members of the community. Its members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.

Members of the technical committee do not have significant authority over other members of the community, although they are to vote on new committers. They have access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.

The technical committee leader is voted for by its memnbers. Once someone has been appointed leader, he/ she remains in that role until choosing to retire, is removed by a majority vote. He/ she  has no additional authority over other members of the technical committee: the role is one of coordinator and facilitator, but also to ensure that all governance processes are adhered to.

Steering committee

This is a group of decision makers with the role of a moderator: the instrumental inspirational authority, expected to draw both the development vision and the guidelines of the community.

All participants in the community are encouraged to provide support to new users. This is provided as a way of growing the community. All support activity within the project is voluntary and is therefore provided upon availability. A user requiring guaranteed response times or results should therefore seek commercial support from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.

Anyone can contribute. For more details, please visit section How to Contribute and Structure and Roles.

Decisions about the future of the project involve all members, from the newest user to the most experienced member. Most of these discussions take place on the forum.

In order to ensure the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.

Decision making typically involves the following steps:

• Proposal
• Discussion
• Vote (if consensus is not reached through discussion)
• Decision

Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should post a proposal on available forums (built within fintp.org, https://github.com/FinTP), on the issue tracker. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.

For more details on how a proposal may reach consensus and be approved, please see Types of approval.

Voting

Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes. For more details please see section Voting.