Opencast as a community and the related software development project have their rules and regulations. The community elects a board that should care about the health and status of the project and the community. The board organizes events like the Opencast conference or cares for the marketing. It also manages to funds of the projects. More information on the current board can be found here. The software development project is lead by a groups of committers. Committers can decide on which new features will be merged into an upcoming version or decide on proposals regarding the future development of software. They also have obligations. Developers for example have to review patches for the software. A contributor to Opencast (that may be an developer, but other contributions like testing and improving documentation or processes can also qualify) can be proposed as a new committer to the project by an existing committer. After this proposal the other committers can vote for the applicant.

Opencast Governance

Updated October 2017

The Opencast community is a collaboration of individuals, higher education institutions and other organizations working together to explore, discuss, define, develop and document best practices and technologies for the management of audiovisual content in academia. The community shares experience with existing technologies and practices, identifies future requirements and collaborates towards possible solutions.

To this end, the Opencast community supports community-driven projects to solve common issues in managing academic video by developing respective open source software products. Today, the community’s main software product is Opencast, an open source software system for lecture capture and video management. At the same time, there are other, technically related or non-related projects originating from the community (LectureSight, Paella Player, pyCA etc.). While the latter will be self-determined and autonomous (and have their own project governance therefore), they are part of the Opencast governance in that the Opencast board seeks to make them flourish as part of a healthy Opencast ecosystem.

The governance of the Opencast community is stipulated in this document, with detailed expectations and practices of the governing bodies, i.e. the board and committers. Collectively, the governance structure has four key purposes:

In order to address the full range of governance the document includes three segments:

  1. Community governance
  2. Project governance
  3. Coordination and review, which span both the community and the projects.

1. Opencast community governance – the board

The community governance centres on a board elected by the Opencast community that is designed to represent the will of the community while providing leadership to support community health long-term.

The board is composed of three categories of individuals, each with a unique selection process and term of service:

Board elections to appoint at least three members will be held every other year at the occasion of the annual community gathering (“Opencast summit”). They will be managed by one board member and one external individual from the community invited by the board. This election committee will

It is the responsibility of the board to promote the current and future health of the community. This will require the board to assess the current state and identify areas of focus. Regardless of changing needs, the board has the following ongoing responsibilities.

The board is not responsible for making project governance decisions, nor for dictating priorities to the committers.

The primary focus areas of the board will shift over time with the evolving needs of the community. As such, board members must have a strong commitment to the success of the community and both the willingness and the ability to fill multiple roles based on the needs of the community.

2. Project governance – contributors and committers

Projects thrive and prosper thanks to the contributions made by individuals: Anyone taking an interest in Opencast can become a contributor therefore, simply by

With a sufficient level of participation and commitment to the project, contributors may be nominated by existing committers to join the committer body according to the governance process described below; this is the project’s interpretation of meritocracy.

Committership allows individuals to participate in the product-related decision-making process as the committer body is driving, managing, and governing the product. They make releases and determine the quality and feature-set of Opencast. We define a committer as an individual contributing actively to the project in a way that deserves participation in the product-related decision-making process. As responsibilities of a committer, this entails

All committers must sign an individual licence agreement (ICLA), the institution they represent a corporate contributor license agreement (CCLA); details are fleshed out at https://www.apereo.org/licensing/agreements. The privileges and rights of being a committer do not come into effect until the agreements have been received and processed.

In return, committers have the following rights:

  1. Make changes to the Opencast source code and other key resources keeping in mind the responsibilities outlined above as well as the working culture of the committer body.
  2. Put forth proposals to the committer body to influence project direction and
  3. participate in resulting decision-making processes according to the project governance stipulated below.

Committers agree to the following approach to project governance:

  1. Project business will be conducted on an open mail list (dev@opencast.org).
  2. Committer proposals will be voted upon according to https://docs.opencast.org/latest/developer/proposal-log/.
  3. Details of this decision-making process can be fleshed out by committers adhering to 1-2 above.
  4. 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, as well as lose the ability to vote and engage in discussion on the committers mailing list. Emeritus committers can become active again upon request, and do not require any additional work prior to reactivation.
  5. 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).

3. Coordinating and Review Process

It is important to note that the board does not own the content of the review, but is responsible for ensuring that the review occurs and for facilitating a process that effectively engages committers and community members. To this end, the community will be called by the board to convene annually (“Opencast summit”). During these meetings the community will:

All discussion and recommended decisions resulting from the coordinating and review process will follow the defined governance processes and must be communicated on list for greater participation and feedback.