forked from videojs/rfcs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
0 parents
commit dc88b46
Showing
4 changed files
with
113 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,65 @@ | ||
- Feature Name: (fill me in with a unique ident, my_awesome_feature) | ||
- Start Date: (fill me in with today's date, YYYY-MM-DD) | ||
- PR: (leave this empty) | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
One paragraph explanation of the feature. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
Why are we doing this? What use cases does it support? What is the expected outcome? | ||
Consider listing any specific Goals and Non-Goals as sub-sections. | ||
|
||
# Guide-level Explanation | ||
[guide-level-explanation]: #guide-level-explanation | ||
|
||
Explain the proposal as if it was already included in the API and you were teaching it to another developer. That generally means: | ||
|
||
* Introducing new named concepts. | ||
* Explaining the feature largely in terms of examples. | ||
* If applicable, provide sample error messages. | ||
|
||
# Reference-level explanation | ||
[reference-level-explanation]: #reference-level-explanation | ||
|
||
This is the technical portion. Explain the design in sufficient detail that: | ||
|
||
* Its interaction with other features is clear. | ||
* It is reasonably clear how the feature would be implemented. | ||
* Corner cases are dissected by example. | ||
|
||
The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. | ||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
Why should we *not* do this? | ||
|
||
# Rationale and alternatives | ||
[rationale-and-alternatives]: #rationale-and-alternatives | ||
|
||
- Why is this design the best in the space of possible designs? | ||
- What other designs have been considered and what is the rationale for not choosing them? | ||
- What is the impact of not doing this? | ||
|
||
# Prior art | ||
[prior-art]: #prior-art | ||
|
||
Discuss prior art, both the good and the bad, in relation to this proposal. | ||
A few examples of what this can include are: | ||
|
||
- Does this feature already exist in a player? | ||
- Has this feature been discussed in a blog post, paper, or presentation? | ||
|
||
This section is intended to encourage you as an author to think about the lessons from other players, and provide readers of your proposal with a fuller picture. | ||
If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages. | ||
|
||
# Unresolved questions | ||
[unresolved-questions]: #unresolved-questions | ||
|
||
- What parts of the design do you expect to resolve through the proposal process before this gets merged? | ||
- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? | ||
- What related issues do you consider out of scope for this proposal that could be addressed in the future independently of the solution that comes out of this proposal? |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
MIT License | ||
|
||
Copyright (c) 2021 video-dev | ||
|
||
Permission is hereby granted, free of charge, to any person obtaining a copy | ||
of this software and associated documentation files (the "Software"), to deal | ||
in the Software without restriction, including without limitation the rights | ||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | ||
copies of the Software, and to permit persons to whom the Software is | ||
furnished to do so, subject to the following conditions: | ||
|
||
The above copyright notice and this permission notice shall be included in all | ||
copies or substantial portions of the Software. | ||
|
||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | ||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | ||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE | ||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, | ||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE | ||
SOFTWARE. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
# Video.js RFCs | ||
|
||
The "RFC" (request for comments) process is for having a place to discussion big changes that may affect many pieces of the Video.js ecosystem so that stakeholders can be confident on the direction of the project. | ||
|
||
Some changes, like bug fixes, small features, and documentation updates, can be done via the normal GitHub process. | ||
|
||
|
||
## Before submitting a proposal | ||
If you have a new idea, it might be worth creating an issue to discuss it a bit first before submitting a proposal to make sure that it's something could be a good fit and won't be less likely to be rejected later on. | ||
|
||
## Submitting a proposal | ||
- Fork the repo | ||
- Copy `0000-template.md` to `proposals/0000-your-feature.md`. Don't change the number yet as that will be updated when the PR is created. | ||
- Fill out your proposal with as much detail as possible. | ||
- Submit a pull request. Once the PR is created, a new commit can be made to update the filename `0000-` prefix and the header of the file to point to the new PR number. | ||
- Folks should now review the proposal and suggest changes. While in the PR, it's expected that many changes may be made. Ideally, please don't rebase commits in the branch as it'll make reviewing only new changes easier. | ||
- At some point, a committer should issue a Call for Consensus (CfC). This CfC will include whether this proposal should be accepted, rejected, or postponed. | ||
- The CfC will last a minimum of 2 weeks to make sure that all collaborators gets a chance to review. If all relevant parties have explicitly finished reviewing before 2 weeks, the CfC may end early. | ||
- If there is enough consensus, the CfC will close successfully. If there is no consensus, the proposal could be rejected or go back to be re-edited. | ||
|
||
## Implementing a proposal | ||
Once a proposal has been accepted, it can start to be implemented. If during implementation, major issues are found, the existing proposal shouldn't be updated but a new proposal should be issued. The old proposal should be updated to link to the new proposal. | ||
|
||
## Inspiration | ||
- [rust-lang/rfcs](https://github.com/rust-lang/rfcs) via [video-dev/hlsjs-rfcs](https://github.com/video-dev/hlsjs-rfcs). | ||
- [WebKit Explainers](https://github.com/WebKit/explainers) | ||
- [Media UI Extensions](https://github.com/video-dev/media-ui-extensions) |
Empty file.