-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Governance model
The DASH Industry Forum (DASH-IF) was created by industry leaders to promote the adoption of the MPEG-DASH standard. The DASH-IF Interoperability Working Group helps this adoption by providing open source implementations of MPEG-DASH to industry under the BSD license.
The scope of this document is to provide a set of guidelines for DASH-IF open source projects and accepting contribution from both DASH-IF members and non-members.
DASH-IF Open Source Projects have an intentionally flat structure. The goal is to create an environment in which newcomers can quickly engage with the project in a positive way. It is our intention to grow the project community through positive engagement with all participants. This section outlines the common roles and responsibilities people choose to adopt.
Project Users – 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 DASH.js project are as widely tested and useable as possible.
Project Contributors – developers that 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.
All participants in a project must initially work as contributors. Contributors who become fully engaged with the project in a sustainable way will be recognized by the community and will be invited to participate directly as project committers.
Project Committers – contributors that have been recognized by the project coordinators and committers as having earned sufficient merit within the project to be given direct commit privileges to the projects code and documentation repository.
Having been awarded such privileges committers become responsible for all aspects of the open source project (see Contribution Process below). In order to provide adequate legal coverage it is necessary for all committers to be a representative of a Contributor Member.
Merit is not transferable between projects. That is, being made a committer on one DASH-IF project does not give the individual the same standing on other projects. Commit privileges must be earned on a per-project basis.
People in this role are members of the DASH-Industry-Forum/DASH.js Committers team
Project Coordinators – are DASH-IF Charter/Contributor Member representatives appointed by the Interoperability Working Group (IWG) chair to coordinate open source projects. The Project Coordinators are responsible for:
- Facilitating the creation of the open source software project and the infrastructure that it needs to operate
- Coordinating and running their assigned project including creation of appropriate development branches and subprojects
- Supervising and leading the project in order to build a meritocratic development environment
- Coordinating the evaluation of the project and proposing to IWG either promoting it to the next release/or to retire it, in case of failure.
- Creating Release Candidates of the project after approval of IWG.
- Reporting status to the IWG on a monthly basis This is a technical role tasked with delivering an open source solution that conforms to the specification produced by the appropriate Working Group. The project coordinator does not define the standards to be implemented, they oversee the production of open source software relating to the standards.
People in this role are members of the DASH-Industry-Forum/Owners team
Interoperability Workgroup Chair – this role is defined in the DASH-IF byelaws.
The chair is responsible for ensuring that the standards are clearly defined and implementable. The chair also ensures that the appropriate Working Group(s) provide meaningful review of software outputs produced by DASH-IF open source projects. Such reviews are limited to ensuring the implementation conforms to the appropriate standards and interoperability guidelines, all technical engagements occur within the confines of the open source project and the roles defined above.
The goal of DASH-IF open source project is to build useful software. Our decision making processes are driven by those who earn merit by ensuring the project can progress unhindered by fruitless discussion or "bikeshedding".
The vast majority of decisions in an open source project are technical in nature and can therefore be driven by direct contributions to testing, feature management, documentation and code. All such decisions are cheap and easily reversible. We therefore make such decisions by "Lazy Consensus" - a process in which those with merit are trusted to "do the right thing". Non-technical decisions are often harder to reverse and are therefore made through "active consensus" - a process in which anyone can actively build consensus amongst those with merit.
Occasionally it is not possible to demonstrate consensus in the community. In such situations deadlocks are broken by conducting a vote within the community. All community members are encouraged to vote, but only project coordinator votes are counted. 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 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.
A valid veto cannot be over-ruled, it can only be withdrawn by its issuer. Any veto must be accompanied by reasoning and be prepared to defend it.
The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote (Project Coordinators). This does not necessarily signify agreement with the veto - merely that the veto is valid.
If an individual disagree with a valid veto, then they must engage the person casting the veto to further discuss the issues. The vetoer is obliged to vote early and to then work with the community to resolve the matter.
If a veto is not withdrawn, the action that has been vetoed must be reversed in a timely manner.
Different actions require different types of approval:
Consensus approval - Consensus approval requires at least 3 binding +1 votes and no binding vetoes.
Lazy majority (majority consensus) A lazy majority vote requires at least 3 binding +1 votes and more binding +1 votes than binding -1 votes.
Lazy approval - An action with lazy approval is implicitly allowed unless any binding -1 vote is received, at which time, depending on the type of action, either lazy majority or consensus approval must be obtained.
2/3 majority - Some actions require a 2/3 majority of PMC members. Such actions typically affect the foundation of the project (e.g. adopting a new codebase to replace an existing product). The higher threshold is designed to ensure such changes are strongly supported. To pass this vote requires at least 2/3 of the binding votes that are cast to be +1.
Unanimous consensus - All of the binding votes that are cast are to be +1 and there can be no binding vetoes (-1).
This section describes the various actions which are undertaken within the project, the corresponding approval required for that action, and those who have binding votes over the action:
| Action | Description | Approval | Binding Votes |
| Code change | A change made to a codebase of the project by a committer. This includes source code, documentation, website content, etc. | Lazy consensus | Project Coordinators |
| Release plan | Defines the timetable and actions for a release. A release plan cannot be vetoed (hence lazy majority). | Lazy majority | Project Coordinators |
| 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. A release cannot be vetoed (hence lazy majority). A Release Manager might choose to get an issue resolved or re-schedule, but that is their decision. Once approved by the project releases must be approved by the Interoperability Working Group before being formally released. | Lazy majority | Project Coordinators |
| 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. | 2/3 majority | Project Coordinators |
| New committer | When a new committer is proposed for the project. | Consensus approval | Project Coordinators |
| Recommend New Project Coordinator | When a new member is proposed as a project coordinator. New project coordinators need to be approved by the Interoperability Working Group, this vote.. | Consensus approval | Project Coordinators |
| Reinstate emeritus member | An emeritus project coordinator can be reinstated. | Consensus approval | Project Coordinators |
| Committer removal | When removal of commit privileges is sought. | Unanimous consensus | Project Coordinators (excluding the committer in question if a project coordinators) |
| Project Coordinator removal | When removal of a Project Coordinator is sought. Removal must be approved by the Interoperability Working Group. | Unanimous consensus | Project Coordinators (excluding the individual in question) |
Votes are normally open for a period of three working days to allow all active voters 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 would need to be raised again later. 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.
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 and a lazy consensus result is acceptable then no vote is necessary.
When a formal vote is deemed necessary the instigator sends the [VOTE] email to the projects 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 email using the voting symbols defined above. 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.