forked from eslint/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.
* New: Initial commit * Fix typos * Fix typo Co-Authored-By: nzakas <[email protected]> * Update proposal to use directories instead of files * Add issue and PR templates * Add note about updating PR link * Remove issue template * Final modifications
- Loading branch information
Showing
4 changed files
with
177 additions
and
2 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,8 @@ | ||
| ## Summary | ||
|
|
||
| <!-- paste the summary from your proposal here --> | ||
|
|
||
| ## Related Issues | ||
|
|
||
| <!-- optional: include links to relevant discussions here --> | ||
|
|
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 |
|---|---|---|
| @@ -1,2 +1,66 @@ | ||
| # rfcs | ||
| Repo for managing Requests For Comments (RFCs) for the ESLint project | ||
| # ESLint RFCs | ||
|
|
||
| Many changes, including bug fixes and documentation improvements, can be | ||
| implemented and reviewed via the normal GitHub pull request workflow. | ||
|
|
||
| However, some changes are "substantial", and we ask that these be put | ||
| through a bit of a design process and produce a consensus among the ESLint Technical Steering Committee (TSC). | ||
|
|
||
| The "RFC" (request for comments) process is intended to provide a | ||
| consistent and controlled path for new features to enter the project. | ||
|
|
||
| ## When you need to follow this process | ||
|
|
||
| You need to follow this process if you intend to make "substantial" | ||
| changes to any part of the ESLint project or its documentation. What constitutes a | ||
| "substantial" change is evolving based on community norms, but may | ||
| include the following. | ||
|
|
||
| * A new ESLint command line option. | ||
| * A new feature of ESLint core. | ||
| * A refactoring of existing ESLint core functionality. | ||
| * Any breaking change. | ||
|
|
||
| In addition to these, the TSC may request an RFC for any other change that it deems "substantial" based on the size or scope of the request. | ||
|
|
||
| If you submit a pull request to implement a new feature without going | ||
| through the RFC process, it may be closed with a polite request to | ||
| submit an RFC first. | ||
|
|
||
| ## Gathering feedback before submitting | ||
|
|
||
| It's often helpful to get feedback on your concept before diving into the | ||
| level of API design detail required for an RFC. A good first step is to contact the [mailing list](https://groups.google.com/group/eslint) or [chatroom](https://gitter.im/eslint/eslint) to get thoughts from the community and the ESLint team before proceeding. | ||
|
|
||
| ## How to submit an RFC | ||
|
|
||
| To submit a new RFC, follow these steps: | ||
|
|
||
| 1. [Fork](https://github.com/eslint/rfcs/fork) the RFC repo. | ||
| 1. Create a directory inside of the `designs` directory. The directory name should begin with the year and include a meaningful description, such as `designs/2018-typescript-support`. | ||
| 1. Copy the appropriate template file from the `templates` directory into the appropriate `designs` subdirectory (such as `designs/2018-typescript-support/README.md`). Be sure to name your file `README.md` so it is easily viewable in the GitHub interface. | ||
| 1. If you want to include images in your RFC, place them in the same directory as the `README.md`. | ||
| 1. Fill in the RFC. Please fill in every section in the template with as much detail as possible. | ||
| 1. Submit a pull request to this repo with all of your files. | ||
| 1. You will receive feedback both from the ESLint community and from the ESLint team. You should be prepared to update your RFC based on this feedback. The goal is to build consensus on the best way to implement the suggested change. | ||
| 1. When all feedback has been incorporated, the ESLint TSC will determine whether or not to accept the RFC. | ||
| 1. RFCs that are accepted will be merged directly into this repo; RFCs that are not accepted will have their pull requests closed without merging. | ||
|
|
||
| ## The RFC life-cycle | ||
|
|
||
| Once an RFC is merged into this repo, then the authors may implement it and submit a pull request to the appropriate ESLint repo without opening an issue. Note that the implementation still needs to be reviewed separate from the RFC, so you should expect more feedback and iteration. | ||
|
|
||
| If the RFC authors choose not to implement the RFC, then the RFC may be implemented by anyone. There is no guarantee that RFCs not implemented by their author will be implemented by the ESLint team. | ||
|
|
||
| Changes to the design during implementation should be reflected by updating the related RFC. The goal is to have RFCs to look back on to understand the motivation and design of shipped ESLint features. | ||
|
|
||
| ## Implementing an RFC | ||
|
|
||
| The author of an RFC is not obligated to implement it. Of course, the | ||
| RFC author (like any other developer) is welcome to post an | ||
| implementation for review after the RFC has been accepted. | ||
|
|
||
| When a pull request has implemented an RFC, the RFC should be updated with a link | ||
| to the PR implementing it. | ||
|
|
||
| **Thanks to the [Ember RFC process](https://github.com/emberjs/rfcs) for the inspiration for ESLint's RFC process.** |
Empty file.
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,103 @@ | ||
| - Start Date: (fill me in with today's date, YYYY-MM-DD) | ||
| - RFC PR: (leave this empty, to be filled in later) | ||
| - Authors: (the names of everyone contributing to this RFC) | ||
|
|
||
| # (RFC title goes here) | ||
|
|
||
| ## Summary | ||
|
|
||
| <!-- One-paragraph explanation of the feature. --> | ||
|
|
||
| ## Motivation | ||
|
|
||
| <!-- Why are we doing this? What use cases does it support? What is the expected | ||
| outcome? --> | ||
|
|
||
| ## Detailed Design | ||
|
|
||
| <!-- | ||
| This is the bulk of the RFC. | ||
| Explain the design with enough detail that someone familiar with ESLint | ||
| can implement it by reading this document. Please get into specifics | ||
| of your approach, corner cases, and examples of how the change will be | ||
| used. Be sure to define any new terms in this section. | ||
| --> | ||
|
|
||
| ## Documentation | ||
|
|
||
| <!-- | ||
| How will this RFC be documented? Does it need a formal announcement | ||
| on the ESLint blog to explain the motivation? | ||
| --> | ||
|
|
||
| ## Drawbacks | ||
|
|
||
| <!-- | ||
| Why should we *not* do this? Consider why adding this into ESLint | ||
| might not benefit the project or the community. Attempt to think | ||
| about any opposing viewpoints that reviewers might bring up. | ||
| Any change has potential downsides, including increased maintenance | ||
| burden, incompatibility with other tools, breaking existing user | ||
| experience, etc. Try to identify as many potential problems with | ||
| implementing this RFC as possible. | ||
| --> | ||
|
|
||
| ## Backwards Compatibility Analysis | ||
|
|
||
| <!-- | ||
| How does this change affect existing ESLint users? Will any behavior | ||
| change for them? If so, how are you going to minimize the disruption | ||
| to existing users? | ||
| --> | ||
|
|
||
| ## Alternatives | ||
|
|
||
| <!-- | ||
| What other designs did you consider? Why did you decide against those? | ||
| This section should also include prior art, such as whether similar | ||
| projects have already implemented a similar feature. | ||
| --> | ||
|
|
||
| ## Open Questions | ||
|
|
||
| <!-- | ||
| This section is optional, but is suggested for a first draft. | ||
| What parts of this proposal are you unclear about? What do you | ||
| need to know before you can finalize this RFC? | ||
| List the questions that you'd like reviewers to focus on. When | ||
| you've received the answers and updated the design to reflect them, | ||
| you can remove this section. | ||
| --> | ||
|
|
||
| ## Help Needed | ||
|
|
||
| <!-- | ||
| This section is optional. | ||
| Are you able to implement this RFC on your own? If not, what kind | ||
| of help would you need from the team? | ||
| --> | ||
|
|
||
| ## Frequently Asked Questions | ||
|
|
||
| <!-- | ||
| This section is optional but suggested. | ||
| Try to anticipate points of clarification that might be needed by | ||
| the people reviewing this RFC. Include those questions and answers | ||
| in this section. | ||
| --> | ||
|
|
||
| ## Related Discussions | ||
|
|
||
| <!-- | ||
| This section is optional but suggested. | ||
| If there is an issue, pull request, or other URL that provides useful | ||
| context for this proposal, please include those links here. | ||
| --> |