Add proposal processes #543
Conversation
Add a new proposal process for API changes. This includes a doc describing the process and a template from which proposals may be made.
rdcronin
requested review from
xeenon,
dotproto,
Rob--W,
oliverdunk and
mukul-p
proposals/proposal_process.md
Outdated
| of a suggestion in a filed issue. As such, these proposals should only be | ||
| used for APIs that have support and commitment to implement from at least | ||
| one browser. | ||
| * Fill out the API Proposal. There are instructions in each section. For any |
There was a problem hiding this comment.
| * Fill out the API Proposal. There are instructions in each section. For any | |
| * Copy the [API Proposal template](proposal_template.md) and fill it out. | |
| There are instructions in each section of the proposal template. For any |
Added link to the template.
proposals/proposal_template.md
Outdated
| **Sponsoring Browser:** The browser vendor committed to implementing this API | ||
| if approved. | ||
|
|
||
| **Contributors:** <other contributors @> |
There was a problem hiding this comment.
What is the @ referring to? Would be nice to suggest the Github handle if any, or any other form of identification (whether an email, or a profile on the codereview site).
There was a problem hiding this comment.
I think Github handle makes the most sense.
proposals/proposal_template.md
Outdated
| resolved directly in the renderer must be asynchronous, and even if | ||
| something can be done in the renderer today, it should frequently be | ||
| asynchronous to prevent future breakage if we move something to the browser |
There was a problem hiding this comment.
| resolved directly in the renderer must be asynchronous, and even if | |
| something can be done in the renderer today, it should frequently be | |
| asynchronous to prevent future breakage if we move something to the browser | |
| resolved directly in a child process must be asynchronous, and even if | |
| something can be done in the child process today, it should frequently be | |
| asynchronous to prevent future breakage if we move something to the parent |
"renderer"/"browser" is Chromium-specific terminology.
I replaced it with the more general "child"/"parent" process terminology. Instead of "parent", "different" could also be used.
There was a problem hiding this comment.
Rephrased, and also added details that extensions usually run in child processes.
proposals/proposal_template.md
Outdated
| | New Permission 1 | Add a proposed warning string for the permission. If there should be no warning, provide justification as to why. Browser vendors can ultimately choose if there should be a warning and what it should be independently, but this can be useful to define especially if it has implications for the likelihood this proposal will succeed or be useful to developers. | | ||
|
|
||
| Document any new permission added by this API. Permissions are frequently the | ||
| same as the API itself, e.g. the browser.storage API has the permission |
There was a problem hiding this comment.
| same as the API itself, e.g. the browser.storage API has the permission | |
| same as the API itself, e.g. the `browser.storage` API has the permission |
proposals/proposal_process.md
Outdated
| one browser. | ||
| * Fill out the API Proposal. There are instructions in each section. For any | ||
| section that is not relevant, you may put "N/A" (likely with a brief summary | ||
| of why the section is not relevant, if it is not immediately obvious). |
There was a problem hiding this comment.
The template is very detailed with its instructions. Is the author supposed to delete the instructions make the doc more concise? If yes, let's emphasize that here (and maybe also in the template)
There was a problem hiding this comment.
Yep, that's the plan. Added a note here and will do so in the template as well.
proposals/proposal_process.md
Outdated
| proposal should be viewed as a possible "next step" from a suggested change or | ||
| developer issue and should imply that one or more browser vendors are actively | ||
| or imminently going to begin implementation. Most feature requests and bug | ||
| reports should continue to be reported as github issues in the WECG repository |
proposals/proposal_process.md
Outdated
| one browser. | ||
| * Fill out the API Proposal. There are instructions in each section. For any | ||
| section that is not relevant, you may put "N/A" (likely with a brief summary | ||
| of why the section is not relevant, if it is not immediately obvious). |
There was a problem hiding this comment.
Yep, that's the plan. Added a note here and will do so in the template as well.
proposals/proposal_template.md
Outdated
| **Sponsoring Browser:** The browser vendor committed to implementing this API | ||
| if approved. | ||
|
|
||
| **Contributors:** <other contributors @> |
proposals/proposal_template.md
Outdated
| resolved directly in the renderer must be asynchronous, and even if | ||
| something can be done in the renderer today, it should frequently be | ||
| asynchronous to prevent future breakage if we move something to the browser |
There was a problem hiding this comment.
Rephrased, and also added details that extensions usually run in child processes.
SHA: 29136ba Reason: push, by Rob--W Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Add a new proposal process for API changes.
This includes:
This should be used for future significant API modifications or additions. This should only be used when there is a browser that has an intent to implement the API change in the near future. This does not replace the process of filing issues for initial discussions around API changes or requests for new features.
More details are included in proposal_process.md.