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.
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:
- Ensure the sustainability and health of the community and its projects.
- Support growth in the form of new adopters, contributors, committers and resources.
- Support effective development and maintenance of Opencast.
- Allow both the community and the projects to achieve their goals of enhancing the open source management of audiovisual content in academia.
In order to address the full range of governance the document includes three segments:
- Community governance
- Project governance
- 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:
- A minimum of three members who are elected by the community to serve a two-year term.
- One member selected by the board to serve a two-year term based on his/her ability to address current needs of the community and/or the board; this seat is optional.
- One member elected by the committers to serve a one-year term (has to be a committer).
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
- communicate the upcoming election at least one month before the summit,
- ask current board members whether they would like to continue their term,
- invite community members interested in joining the board to nominate themselves for election,
- identify and implement an online voting process to elect individual members, and
- communicate nominees and stipulate the voting procedure in situ and/or online.
- Each nominee will be voted upon individually with a “yes” or “no”; nominees with more “yes” votes than “no” votes are being elected to serve the board for another two years. The board is being voted upon by individuals representing the community, defined by their subscription to the Opencast users’ mailing list (firstname.lastname@example.org); board members have a right to participate in these elections. The election committee will also verify the right to vote, count all votes, communicate which board members have been elected, and keep the detailed voting results confidential.
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.
- Drive strategic planning for Opencast.
- Actively engage with institutions, organisations, and individuals forming the community.
- Draw new organizations into the community.
- Identify and execute processes to secure needed resources of any kind, funding, staff, etc.
- Act on behalf of the Opencast community in creating partnerships that serve the goals of the community and/or its projects.
- Actively participate in community communications activities and community building efforts; in particular, the board is to organize the annual Opencast summit.
- Select and invite those board members that require nomination and selection by the board.
- Drive and monitor relevant communication channels (website, social media).
- Effectively manage financial contributions made to the community as well as expenditures; the board has to report on both at the annual meeting.
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
- participating in discussions,
- reporting bugs,
- editing documentation,
- supporting new users,
- fixing bugs,
- or enhancing the project’s health in other forms.
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
- contributing time to support the common good of the project,
- supporting the review and release process, quality assurance and testing processes for the project as stipulated in https://docs.opencast.org/latest/developer,
- being active and engaging in the broader community, including supporting adopters and providing prompt feedback, and
- fostering a collegial environment between the group of committers.
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:
- 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.
- Put forth proposals to the committer body to influence project direction and
- participate in resulting decision-making processes according to the project governance stipulated below.
Committers agree to the following approach to project governance:
- Project business will be conducted on an open mail list (email@example.com).
- Committer proposals will be voted upon according to https://docs.opencast.org/latest/developer/proposal-log/.
- Details of this decision-making process can be fleshed out by committers adhering to 1-2 above.
- 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.
- 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:
- Share updates that span projects and community status and progress.
- Review status and progress of the projects and the community as well as governance processes with the objective of validating that existing processes are serving the project and community well, or enhancing the processes to improve results.
- Review the project roadmap, discuss their vision for the product, thus bringing together the views of committers and the broader Opencast community.
- Communicate and seek to align community and development priorities.
- Capture future development and collaboration opportunities beyond the current roadmap.
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.