-
Notifications
You must be signed in to change notification settings - Fork 2
Governance Model
The Streaming Video Alliance (SVA) was created in 2014 by industry leaders to solve critical technical challenges in delivering high-quality streaming video at scale. The name was changed to the Streaming Video Technology Alliance (SVTA) in 2022 to communicate to the industry the organization’s single-minded focus on technology challenges (versus business challenges). SVTA Working Groups, spanning the streaming workflow, produce documents and software code as part of their project work.
The scope of this document is to provide a set of guidelines for SVTA open-source projects and accepting contributions from both members and non-SVTA members.
SVTA open-source projects, which are open to contributions outside of SVTA members, are intended to develop and promote a community around the development of code that can be used throughout the industry. Each project will be structured and run differently depending upon how it is made available beyond SVTA members. For projects like this, where contribution can be made by non-SVTA members, we have the following roles:
These contributors provide feedback to the developers in the form of bug reports and feature suggestions. Users are encouraged to increase their involvement by providing concrete contributions that can be directly applied (see Project Contributors below). However, there is no requirement to do so. Feedback from users helps ensure that the outputs of the Common Media Library project are as widely tested and usable as possible.
These contributors provide patches against the project and make suggestions for code and documentation improvements. Any interested party can contribute as described in the Contribution Process later in this document. Any one contributing code must first agree to the DCO that is operationalized as part of the Common Media Library repo.
These contributors are reserved for SVTA members. All SVTA projects, including the Common Media Library, operate under the BDFL model. As such, the project is managed by the SVTA working group, in the case of the Common Media Library this is the Players and Playback group, under which the project was begun or to which the project has been assigned by the SVTA Board of Directors or Technical Committee. Based on a Project Contributor’s contributions, a Project Manager can elevate them to a Project Committer status at which time they become part of the group responsible for all aspects of the open-source project. To provide adequate legal coverage, it is necessary for all committers to be a representative of an SVTA member company. It is important to note that roles are not transferable between SVTA open-source projects. Being elevated to a Project Committer status on one SVTA project does not give the individual the same standing on other projects.
These people are identified by the current working group chairs (identified in the CONTRIBUTORS.md file in the root of the project repo) and are responsible for:
- Facilitating the creation of the open-source software project and/or the infrastructure it needs to operate
- Coordinating and running their assigned project including creation of appropriate development branches and sub-projects
- Supervising and leading the project to build the software as defined within the approved scoping document (see Scoping Document section below)
- Coordinating the evaluation of the project, proposing modifications to the scoping document (through the normal SVTA working group processes), and recommending closure of the project if/when that is appropriate
- Creating release candidates of the project in line with the project scope
- Reporting status to the managing working group on a monthly basis.
This role is only available to people of SVTA member companies.
All SVTA open-source projects are governed by a scoping document. This document, as per the SVTA By-Laws, is ratified through the standard ratification process and represents the scope of the open-source project, not how it will be implemented. This document generally covers functionality and features. A link to this document is found in the SCOPING.md file in the root of the repo.
The goal of SVTA open-source projects is to create useful software or reference code that can be used by the industry to improve the management or delivery of streaming video. Decision-making within these projects is handled by the SVTA working group that manages the project.
Approval of committed code is handled by the Project Managers who are tasked, by the chairs of the working group under which the project falls, to ensure the highest quality of code.
Any proposed changes to the scope, which can be submitted by any contributor to the project, will be presented to the working group for review by the Project Managers. If the scope changes in a meaningful way, the new scoping document must be ratified by the SVTA members as per the ratification process explained in the SVTA By-Laws.
Because SVTA open-source projects are governed by the BDFL model, consensus is handled in two ways:
- Project Contributors. As part of the Project Managers responsibilities, Project Contributors will be requested, on occasion, to provide their input to the future of the project. Based on this input, the Project Manager will present this consensus to the working group.
- Working Group. Any material changes to the project will be made by the working group as part of the normal working group processes. If this results in modifications to the Scoping Document, the document will need to be approved through the normal SVTA ratification process as defined in the SVTA By-Laws.
- SVTA. When a Scoping Document is amended in such a way that represents a material change to the originally approved document, SVTA Principal Members will have a right to comment and vote on the proposed changes as per the SVTA Ratification Process outline in the SVTA By-Laws.
For the first type of consensus, the Project Managers may employ a standard voting convention to determine what shall be carried to the working group for review and/or voting. All community members are encouraged to vote. It is expected that project coordinators will, wherever possible, reflect the overall opinions of the community in their own votes.
Votes are clearly indicated by a subject line starting with [VOTE]. Discussion and proposal should have happened prior to the vote. Voting is carried out by replying to the vote mail. See voting procedure below. Votes are expressed using one of the following symbols:
- +1 - "Yes," "Agree," or "the action should be performed." In general, this vote also indicates a willingness on the behalf of the voter to assist with "making it happen".
- +0 - This vote indicates a willingness for the action under consideration to go ahead. The voter, however, will not be able to help.
- -0 - This vote indicates that the voter does not, in general, agree with the proposed action but is not concerned enough to prevent the action going ahead.
- -1 - This is a negative vote. On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. Wherever possible a -1 vote to include an alternative course of action.
- abstain - People can abstain from voting. They can either remain silent or express their reason.
For the second type of consensus, voting is handled within the working group by SVTA members.
Because SVTA open-source projects are governed under the BDFL model, there is no binding decision regarding consensus from within the Project Contributors. It is expected that the Project Manager(s) will “act in good faith” with regards to bringing the voted-upon consensus from the contributors to the working group for review and/or discussion.
Votes are normally open for a period of three working days to allow all active contributors time to consider the vote. This can be extended by three working days if there is insufficient engagement in the vote. If there is still insufficient interest after this extension then the vote fails, and the Project Manager can proceed with the presentation of proposed changes to the Working Group. Votes relating to code changes are not subject to a strict timetable, but should be made as timely as possible.
Be careful about holidays when calling a vote. This is hard when we do not know customs in every part of the world. So if someone knows that there is a problem with the vote timing, then please say so.
There may be various activities carried out within an SVTA open-source project which require approval.
| Action | Description | Approval |
|---|---|---|
| Code change | A change made to a codebase of the project by a committer. This includes source code, documentation, website content, etc. | Project Manager and/or Working Group |
| Release plan | Defines the timetable and actions for a release. | Project Manager and/or Working Group |
| Product release | When a release of one of the project's products is ready, a vote is required to propose the release as an official release of the project. Once approved by the Project Manager, a release must be approved by the Working Group before being formally released. | Project Manager (based on contributor consensus) |
| Adoption of new codebase | When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code base will continue. This also covers the creation of new sub-projects within the project. | Project Manager (based on contributor consensus) |
| New committer | When a new committer is proposed for the project. | Project Manager |
| New project manager | When a new member is proposed as a project coordinator. New project managers are approved by the governing Working Group. | Working Group co-chairs |
| Committer removal | When removal of commit privileges is sought. | Project Manager |
| Project Manager removal | When removal of a Project Manager is sought. Removal must be approved by the governing Working Group. | Working Group co-chairs and/or SVTA staff |
Discussion about the topic must have already happened in a [Proposal] or [Discuss] email thread to express the issues and opinions. This [Proposal] or [Discuss] thread will have been used to build consensus around a specific outcome. The [Vote] thread is to ratify this consensus if that is felt to be necessary.
In many cases there will have been no objections and no counter proposals during the discussion phase. If this is the case then it may not be necessary to call a formal vote as it may be sufficient to simply state there is consensus, define the scope of the agreement, and indicate an intention to continue under this assumption. If there is still no objection after 72 hours then no vote is necessary.
When a formal vote is deemed necessary the instigator sends the [VOTE] email to the project mailing list. The email must describe the issue with no ambiguity and in a positive sense. Define the date and time for the end of the vote period and link to the discussion thread.
Votes are expressed by replying via email using the voting symbols defined previously. Voters can change their vote during the timeframe. At the end of the vote period, the instigator tallies the number of final votes and reports the results.
In the event that a Project Manager is not acting on the best behalf of the project or the contributors and is unwilling to engage in productive discussions, Project Contributors can raise an issue to the SVTA through the email [email protected]. This subject line of this email should clearly state the project name (i.e., Common Media Library) followed by the concern (i.e., issue with John Smith). The body of the email should include clear and concrete references to a failure in communication regarding an issue with the management of the project (i.e., John Smith has failed to respond to any emails or engage in any discussion threads and work on the project has stalled as a result). The email will be addressed by a member of the SVTA staff.
All SVTA open-source projects will have the following management roles and responsible parties:
| Management function | Responsible party |
|---|---|
| Maintain code within repo | Manager |
| Maintain repo within the SVTA organization | SVTA staff |
| Removing contributors | Manager |
| Removing or adding managers | Working Group chairs |
| Approving commitments from contributors | Manager |
| Addressing contributor requests | Manager and, when not possible, SVTA staff |
| Modifying scope of open-source software within the repo | Working Group (ratification of a revised scoping document may or may not be necessary) |
All SVTA open-source projects have the following expectations of anyone involved:
- Any contributions will be the original work of the contributor. If a contributor wishes to provide input that is from another project (perhaps another open-source library), it will need to be cleared by the Manager first. All requests for this should be sent to [email protected] (this mailbox will be accessible by all SVTA staff).
- All comments and interaction within the project are made under the provisions of the CODE_OF_CONDUCT.md file.
- All contributors must agree to the DCO