mirror of https://github.com/tc39/test262.git
77 lines
3.8 KiB
Markdown
77 lines
3.8 KiB
Markdown
- Feature Name: (fill me in with a unique ident, `my-awesome-feature`)
|
|
- Start Date: (fill me in with today's date, YYYY-MM-DD)
|
|
- RFC PR: [tc39/test262#0000](https://github.com/tc39/test262/pull/0000)
|
|
|
|
# Summary
|
|
|
|
One paragraph explanation of the feature.
|
|
|
|
# Motivation
|
|
|
|
Why are we doing this?
|
|
What use cases does it support?
|
|
What is the expected outcome?
|
|
|
|
# Guide-level explanation
|
|
|
|
Explain the proposal from the point of view of whichever of test262's stakeholders (test writers, test suite consumers, proposal writers, test262 maintainers) is going to be affected by it.
|
|
Making lots of use of examples is encouraged.
|
|
|
|
For RFCs oriented towards the tests and test harness, this section should focus on how stakeholders should think about the change, and give examples of its concrete impact.
|
|
For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms.
|
|
|
|
# Reference-level explanation
|
|
|
|
This is the technical portion of the RFC.
|
|
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
|
|
|
|
Why should we *not* do this?
|
|
|
|
# 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
|
|
|
|
Discuss prior art, both the good and the bad, in relation to this proposal.
|
|
A few examples of what this can include are:
|
|
|
|
- For test harness proposals: Does this feature exist in other test harnesses and what experience have their community had?
|
|
Is the feature generally considered a net positive?
|
|
- For policy proposals: Is this done by some other community and what were their experiences with it?
|
|
|
|
This section is intended to encourage you as an author to think about the lessons from other similar features elsewhere, and provide readers of your RFC 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 elsewhere.
|
|
|
|
Note that while precedent set elsewhere is some motivation, it does not on its own motivate an RFC.
|
|
Please also take into consideration that test262 sometimes intentionally diverges from common test conventions, due to its unique requirements.
|
|
|
|
# Unresolved questions
|
|
|
|
- What parts of the design do you expect to resolve through the RFC process before this gets merged?
|
|
- What parts of the design do you expect to resolve through the implementation of this feature?
|
|
- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
|
|
|
|
# Future possibilities
|
|
|
|
Think about what the natural extension and evolution of your proposal would be and how it would affect the project as a whole in a holistic way.
|
|
Try to use this section as a tool to more fully consider all possible interactions with the project in your proposal.
|
|
Also consider how this all fits into the roadmap for the project.
|
|
|
|
This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related.
|
|
|
|
If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything.
|
|
|
|
Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs.
|
|
The section merely provides additional information.
|