Become a part of the CRITs Community!
CRITs has a strong community of users and developers. They are the driving force behind the innovation that makes CRITs such an integral part of a successful threat defense solution. Are you interested in joining and contributing to that community? Read more below about what you can do to help!
Become a User!
Users are community members who have a need for the project. They are the most important members of the community and without them the project has no purpose. Anyone can be a user; there are no special requirements.
The project asks its users to participate in the project and community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user contributions include (but are not limited to):
- Evangelizing about the project (e.g. a link on a website and word-of-mouth awareness raising).
- Informing developers of strengths and weaknesses from a new user perspective.
Become a Contributor!
Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor and contributions can take many forms. There is no expectation of commitment to the project, no specific skill requirements and no selection process.
In addition to their actions as users, contributors may also find themselves doing one or more of the following:
- Supporting new users (existing users are often the best people to support new users.
- Reporting bugs.
- Identifying requirements.
- Providing graphics and web design.
- Assisting with project infrastructure.
- Writing documentation.
- Fixing bugs.
- Adding features.
Become a Committer!
Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project's resources. That is, they can make changes directly to project outputs, without having to submit changes via patches.
Their work continues to be reviewed by the community before acceptance in an official release. The key difference between a Committer and a Contributor is that a committer can accept pull requests and take responsibility for those changes.
New committers are nominated by any existing committer. Once they have been nominated, there will be a vote by the project management committee (PMC). A majority vote is required for a new committer to be accepted. The vote and the results should be historically logged for record and reference for the other committers.
Committership can be removed by the PMC in some 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 a member of the PMC.
The Project Management Committee
The PMC has additional responsibilities over and above those of a committer. These responsibilities ensure the smooth running of the project. PMC members are expected to review code contributions, participate in strategic planning, approve changes to the governance model, manage marketing activities for the project and manage the copyrights within the project outputs.
Membership of the PMC is by invitation from the existing PMC members. A nomination will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members.
Once someone has been appointed to the PMC, they remain in that role until they choose to retire or the PMC casts a two-thirds majority vote to remove them.
At no time can the PMC exist with less than two individuals. To ensure voting always has a majority the PMC should always have an odd number of individuals.
At no time will anyone (User, Contributor, Committer, PMC, etc.) be held financially responsible for any aspect of the project. If there is a financial need that arises, the PMC will discuss what that need is and how best to fulfill it.
Decision Making Process
Decisions about the future of the project are made through discussion with members of the community. All non-sensitive project management discussion takes place on the project contributors' mailing list. Occasionally, sensitive discussion occurs on a private list.
In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates on a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote. Lazy consensus means that most decisions are made by following a process of propose:
discuss -> vote (only if necessary) -> decide
Only those that explicitly object need to participate in the discussion. A vote is only held if consensus can't be reached through discussion.
Any decisions and/or votes shall be open for a maximum period of two weeks. At the end of the voting period, a final decision is made with the available votes and results/reasons are made available to the appropriate parties.
Not all decisions can be made using lazy consensus. 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. However, only project committers and/or PMC members (as defined above) have binding votes for the purposes of decision making. If a member decides to vote "no", they must also provide an explanation so the rest of the voters can understand their reasoning.
All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a community member.