Committers and Contributors

What is a committer, and how does that differ from a contributor?

The Opencast project welcomes all those who are interested in contributing in concrete ways. Contributions can take many forms, and there are various mechanisms by which one can contribute (signing up for the mailing list or browsing our issue tracker are both great places to start). Anyone can become a contributor, and there is no expectation of future commitment to the project, no specific skill requirements, and no selection process. Some of the contributions individuals have given in the past include:

  • Supporting new users (users are often the best people to support new users)
  • Reporting bugs
  • Identifying requirements
  • Providing design and pedagogical direction
  • Adding features and fixing bugs
  • Assisting with project infrastructure
  • Writing documentation
  • Assisting in translation of both documentation and the system itself
  • Performing Quality Assurance tasks as needed as part of the QA process prior to release

As contributors gain experience and familiarity with the project they generally find that making such contributions becomes easier. With a sufficient level of participation and commitment to the project, contributors may be nominated by existing committers to join the committer body. While similar in day-to-day activities as contributors, committers have shown a dedicated interest in supporting the project over the longer term. Committership allows individuals to more easily carry on with their project related activities by giving them direct access to the projects resources. In Opencast, the project's resources include not only code, but also designs, documents, and other non-code resources. As such, we welcome and value committers both in the traditional sense (e.g. programmers) as well as in the broader sense (e.g. people who are committed to the project).

The committer body is the group of individuals who drive, manage, and govern the product. They make releases, set policy, and determine the both the quality and feature-set of Opencast.

Responsibilities of a committer

Committers responsibilities are centered around two key principles, that there is a commitment to excellence and success, and that there is a commitment to being active and involved. These commitments are demonstrated through activities such as:

  • Being involved in quality assurance of the source code, documentation, designs, and other project pieces.
  • Being active and engaging in the broader community, including supporting adopters and providing prompt feedback.
  • Knowing when a change is beyond your ability and asking for help.
  • Keeping informed of project governance and direction.
  • Fostering a collegial environment between the group of committers.
  • Ensuring that incoming code adheres to our license requirements. Minor patches can be accepted without concern, but the main reviewer must ensure that a CLA (and CCLA) is in place prior to merging in the contribution.
  • 20% of the time a committer invests to the project is to be allocated for general purposes, i.e. work not directly associated with the committer's individual or institutional concerns.

All committers must signed a ICLA. The privileges and rights of being a committer do not come into effect until an ICLA has been received and processed. The ICLA, as well as the list of ICLA signatories, can be found here. Your employer will also need to sign a CCLA as well.

How do I become a committer?

Committers must be recommended by existing committers and pass a vote of the committer body. Committers proposing a contributor for commit rights should present a solid background of why this person would be a good fit, as well as their work history within the project. This history, baring special circumstances, should be significant and of a high quality.

What happens if I stop contributing?

Committer status can be lost through any of the methods below:

  • Committer Emeritus: By being absent or inactive for a period of six months or more, or by request, a committer enters emeritus status. No vote is required to enter this state, and committer status can be restored just by making an inquiry to the project infrastructure group. While in emeritus, committers lose access to project resources (e.g. git write access), as well as lose the ability to vote and engage in discussion on the committers mailing list.
  • Revocation of Commit Privileges: A committer may make a proposal to remove an individual from the committer body. Discussion and voting happen on the confidential committers mailing list, and the committer in question is not entitled to a vote (though they do get to participate in the discussion).