Prepare repo for writing Proposals (#5)

Author: gkatsev

template.md renamed to 0000-template.md

@@ -11,6 +11,7 @@ One paragraph explanation of the feature.
 [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
@@ -61,4 +62,4 @@ If there is no prior art, that is fine - your ideas are interesting to us whethe
 
 - 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?
+- 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?

README.md

@@ -1,16 +1,33 @@
 # media-ui-extensions
 Extending the HTMLVideoElement API (`<video>`) to support advanced video player user-interface features
 
-With the addition of [web components](https://developer.mozilla.org/en-US/docs/Web/Web_Components) to the browser, video player developers can create custom elements that mimic the video tag API, with goals of creating stand-in compatiblity with the video tag and compatibility across players. The video tag API is however lacking some important functions to support modern player UIs, including playback quality/resolution selection and awareness of ads. This repo is intended to capture requests and proposals for those functions.
+With the addition of [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components) to the browser, video player developers can create custom elements that mimic the video tag API, with goals of creating stand-in compatibility with the video tag and compatibility across players. The video tag API is however lacking some important functions to support modern player UIs, including playback quality/resolution selection and awareness of ads. This repo is intended to capture requests and proposals for those functions.
 
-## Submitting a proposal
-Use `template.md` to frame your proposal and make a pull-request to add your proposal document to the `proposals` directory.
+## Goals for Proposals
+We want these proposals to be something that we can eventually propose to the Media WG or WhatWG as additional features to the video element and anything related. In the meantime, proposals accepted to media-ui-extensions can be used as a specification to keep things interoperable between implementers.
+
+## 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.
 
-Inspired by [rust-lang/rfcs](https://github.com/rust-lang/rfcs) via [video-dev/hlsjs-rfcs](https://github.com/video-dev/hlsjs-rfcs).
+## 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.
 
-## Submitting a request
-Use the github issues to request and disucss a desired feature/function at a high level.
+## 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.
 
 ## Resources
-* [MDN video element docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video)
-* [WHATWG spec](https://html.spec.whatwg.org/multipage/media.html#the-video-element)
+- [MDN video element docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video)
+- [WHATWG spec](https://html.spec.whatwg.org/multipage/media.html#the-video-element)
+- [Media Working Group](https://github.com/w3c/media-wg/)
+
+## 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)
+