Docs: Change to rule acceptance

docs/developer-guide/contributing/index.md

@@ -21,6 +21,10 @@ Think you found a problem? We'd love to hear about it. This section explains how
 
 We get a lot of proposals for new rules in ESLint. This section explains how we determine which rules are accepted and what information you should provide to help us evaluate your proposal.
 
+## Proposing a [Rule Change](rule-changes)
+
+Want to make a change to an existing rule? This section explains the process and how we evaluate such proposals.
+
 ## Requesting a [Change](changes)
 
 If you'd like to request a change other than a bug fix or new rule, this section explains that process.

docs/developer-guide/contributing/new-rules.md

@@ -4,7 +4,9 @@ layout: doc
 ---
 # New Rules
 
-ESLint is all about rules. For most of the project's lifetime, we've had over 100 rules, and that list continues to grow. However, we can't just accept any proposed rule because all rules need to work cohesively together. As such, we have some guidelines around which rules can be part of the ESLint core and which are better off as custom rules and plugins.
+ESLint is all about rules. For most of the project's lifetime, we've had over 200 rules, and that list continues to grow. However, we can't just accept any proposed rule because all rules need to work cohesively together. As such, we have some guidelines around which rules can be part of the ESLint core and which are better off as custom rules and plugins.
+
+**Note:** As of 2016, we accept only rules that are deemed extremely important for inclusion. We prefer that new rules be implemented in plugins.
 
 ## Core Rule Guidelines
 
@@ -30,10 +32,20 @@ If you want to propose a new rule, [create an issue](https://github.com/eslint/e
 
 We need all of this information in order to determine whether or not the rule is a good core rule candidate.
 
-## Resource Limitations
+## Accepting a Rule
+
+In order for a rule to be accepted in the ESLint core, it must:
+
+1. Fulfill all the criteria listed in the "Core Rule Guidelines" section
+1. Have an ESLint team member champion inclusion of the rule
+1. Be very important for ESLint users because it either catches a serious problem or allows styling of code in accordance with a popular style guide
+
+Keep in mind that we have over 200 rules, and that is daunting both for end users and the ESLint team (who has to maintain them). As such, any new rules must be deemed of high importance to be considered for inclusion in ESLint.
+
+## Implementation is Your Responsibility
 
-Please keep in mind that we receive a lot of rule proposals and the ESLint team is completely a volunteer team that works in its free time to maintain ESLint. As a result, even if we like the idea for a rule, we may not have the resources to implement it. You greatly increase the likelihood of getting a new core rule into ESLint if you are willing to implement it yourself. The team is very good at guiding first-time contributors through the rule creation process.
+The ESLint team doesn't implement new rules that are suggested by users because we have a limited number of people and need to focus on the overall roadmap. Once a rule is accepted, you are responsible for implementing and documenting the rule. You may, alternately, recruit another person to help you implement the rule. The ESLint team member who championed the rule is your resource to help guide you through the rest of this process.
 
-## Creating Your Own Rules
+## Alternative: Creating Your Own Rules
 
 Remember that ESLint is completely pluggable, which means you can create your own rules and distribute them using plugins. We did this on purpose because we don't want to be the gatekeepers for all possible rules. Even if we don't accept a rule into the core, that doesn't mean you can't have the exact rule that you want. See the [working with rules](../working-with-rules) and [working with plugins](../working-with-plugins) documentation for more information.

docs/developer-guide/contributing/rule-changes.md

@@ -0,0 +1,30 @@
+---
+title: Rule Changes
+layout: doc
+---
+# Rule Changes
+
+Occasionally, a core ESLint rule needs to be changed. This is not necessarily a bug, but rather, an enhancement that makes a rule more configurable. In those situations, we will consider making changes to rules.
+
+## Proposing a Rule Change
+
+If you want to propose a rule change, [create an issue](https://github.com/eslint/eslint/issues/new?body=**What%20version%20of%20ESLint%20are%20you%20using%3F**%0A%0A**What%20rule%20do%20you%20want%20to%20change%3F**%0A%0A**What%20code%20should%20be%20flagged%20as%20incorrect%20with%20this%20change%3F**%0A%0A**What%20happens%20when%20the%20rule%20is%20applied%20to%20this%20code%20now%3F**%0A%0A%0A) be sure to include:
+
+1. The version of ESLint you are using
+2. The rule you want to change
+3. The code you want to be flagged as incorrect
+4. What happens when the rule is applied to the code without your change
+
+We need all of this information in order to determine whether or not the change is a good candidate for inclusion.
+
+## Accepting a Rule Change
+
+In order for a rule change to be accepted into ESLint, it must:
+
+1. Adhere to the [Core Rule Guidelines](new-rules#core-rule-guidelines)
+1. Have an ESLint team member champion the change
+1. Be important enough that rule is deemed incomplete without this change
+
+## Implementation is Your Responsibility
+
+The ESLint team doesn't implement rule changes that are suggested by users because we have a limited number of people and need to focus on the overall roadmap. Once a rule change is accepted, you are responsible for implementing and documenting it. You may, alternately, recruit another person to help you. The ESLint team member who championed the rule is your resource to help guide you through the rest of this process.

docs/maintainer-guide/issues.md

@@ -48,12 +48,13 @@ The steps for triaging an issue are:
 1. Once it's clear what type of issue it is, make sure all of the relevant information is provided:
   * **Bugs**: See [bug reporting guidelines](/docs/developer-guide/contributing/reporting-bugs)
   * **New Rules:** See [rule proposal guidelines](/docs/developer-guide/contributing/new-rules)
+  * **Rule Changes:** See [rule change proposal guidelines](/docs/developer-guide/contributing/rule-changes)
   * **Other Changes:** See [change proposal guidelines](http://eslint.org/docs/developer-guide/contributing/changes)
 1. Next steps:
   * **Questions:** answer the question and close the issue when the conversation is over.
   * **Bugs:** if you can verify the bug, add the "accepted" label and ask if they would like to submit a pull request.
-  * **New Rules:** if you are willing to champion the rule (meaning you believe it should be included in ESLint core), then add a comment saying you will champion the issue and add an "accepted" label. As the champion, it's your job to guide the rule creation process until it's complete, so only champion a rule that you have time to implement or help another contributor implement.
-  * **Rule Changes:** if you are willing to champion the change, and the change would not be breaking (requiring a major version increment), then add a comment saying that you will champion the issue and add an "accepted" label. As with new rules, the champion is expected to guide the change through to completion.
+  * **New Rules:** if you are willing to champion the rule (meaning you believe it should be included in ESLint core and you will take ownership of the process for including it), then add a comment saying you will champion the issue. As the champion, it's your job to gain consensus from the ESLint team on inclusion, guide the rule creation process until it's complete, so only champion a rule that you have time to implement or help another contributor implement. Once consensus has been reached on inclusion, add the "accepted" and "help wanted" labels.
+  * **Rule Changes:** if you are willing to champion the change, and the change would not be breaking (requiring a major version increment), then add a comment saying that you will champion the issue. As with new rules, the champion is expected to gain consensus from the ESLint team on inclusion and to guide the change through to completion. Once consensus has been reached on inclusion, add the "accepted" and "help wanted" labels.
   * **Breaking Changes:** if you suspect or can verify that a change would be breaking, label it as "Breaking".
   * **Duplicates:** if you can verify the issue is a duplicate, add a comment mentioning the duplicate issue (such as, "Duplicate of #1234") and close the issue.
 1. Regardless of the above, always leave a comment. Don't just add labels, engage with the person who opened the issue by asking a question (request more information if necessary) or stating your opinion of the issue. If it's a verified bug, ask if the user would like to submit a pull request.
@@ -85,3 +86,7 @@ Any team member may close an issue if any of the following is true:
 1. The request is outside the scope of the project
 
 In general, it's better to close issues sooner rather than later. It gives people better feedback about the issue affects the project roadmap.
+
+## Consensus
+
+Consensus is reached on issues when there are at least three team members who believe the change is a good idea and no one who believes the change is a bad idea. If consensus cannot be reached, then a consensus among reviewers must be achieved where no one believes it is a bad idea. If consensus among reviewers cannot be achieved, the reviewers will vote and majority wins.