Skip to content

Commit

Permalink
Scaffold Repo
Browse files Browse the repository at this point in the history
  • Loading branch information
gkatsev committed May 4, 2023
0 parents commit dc88b46
Show file tree
Hide file tree
Showing 4 changed files with 113 additions and 0 deletions.
65 changes: 65 additions & 0 deletions 0000-template.md
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?
21 changes: 21 additions & 0 deletions LICENSE
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.
27 changes: 27 additions & 0 deletions README.md
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 added proposals/.gitkeep
Empty file.

0 comments on commit dc88b46

Please sign in to comment.