Docs: Update RFC process based on TSC meeting discussion (#61)

* Docs: Update RFC process based on TSC meeting discussion

* Update README.md

Co-authored-by: Kai Cataldo <kai@kaicataldo.com>

Co-authored-by: Kai Cataldo <kai@kaicataldo.com>

README.md

@@ -29,10 +29,13 @@ 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.
+Before submitting an RFC, open an issue in the repository where you'd like to make the change (for example, to make a change to ESLint, open an issue in the [eslint/eslint](https://github.com/eslint/eslint) repository). The purpose of opening the issue is to gather feedback from the community and the ESLint team to ensure that there is enough interest to put together an RFC.
 
-## How to submit an RFC
+Once the ESLint team has indicated that there is enough interest, you'll be asked to create an RFC to describe the change you'd like to make in more detail.
+
+**Note:** Please do not submit a pull request with your prototype or proof-of-concept. Instead, include a link to your fork or branch when you submit your RFC (see next section).
+
+## How to submit an RFC to this repo
 
 To submit a new RFC, follow these steps:
 
@@ -48,9 +51,11 @@ To submit a new RFC, follow these steps:
 
 When an RFC is submitted, it goes through the following process:
 
-1. **Initial commenting period (21 days minimum)** - the community and ESLint team are invited to provide feedback on the proposal. During this period, you should expect to update your RFC based on the feedback provided. Very few RFCs are ready for approval without edits, so this period is important for fine-tuning ideas and building consensus. (A PR in the initial commenting period has the **Initial Commenting** label applied.) The initial commenting period must last at least 21 days to allow the team and community enough time to comment. The TSC may decide to reject the RFC without promoting it to the final commenting period.
+1. **Initial commenting period (21-90 days)** - the community and ESLint team are invited to provide feedback on the proposal. During this period, you should expect to update your RFC based on the feedback provided. Very few RFCs are ready for approval without edits, so this period is important for fine-tuning ideas and building consensus. (A PR in the initial commenting period has the **Initial Commenting** label applied.) The initial commenting period must last at least 21 days and not more than 90 days to allow the team and community enough time to comment. The TSC may decide to reject the RFC without promoting it to the final commenting period.
 1. **Final commenting period (7 days)** - when all feedback has been addressed, the pull request author requests a final commenting period where ESLint TSC members provide their final feedback and either approve of the pull request or state their disagreement. (A PR in the final commenting period has the **Final Commenting** label applied.) ESLint TSC members are notified through GitHub when an RFC has passed into the final commenting period.
-1. **Approval and Merge** - if consensus has been reached on approving the RFC, the pull request will be merged. If consensus is not reached on the pull request then the RFC will be discussed at the next TSC meeting to determine whether or not to move forward.
+1. **Approval and Merge** - if the TSC reaches consensus on approving the RFC, the pull request will be merged. If consensus is not reached on the pull request then the RFC will be discussed at the next TSC meeting to determine whether or not to move forward.
+
+**Note:** If two or more RFCs attempt to address the same problem or need, the TSC will consider all of the competing RFCs together to determine which RFC to approve. Alternately, the TSC may request that competing RFCs be merged in order to create a hybrid solution.
 
 ## The RFC Lifecycle