Docs: Update contributing docs for jQuery Foundation

eslint · Apr 19, 2016 · 146f976 · 146f976
1 parent 4f22365
commit 146f976
Show file tree

Hide file tree

Showing 4 changed files with 12 additions and 21 deletions.
diff --git a/docs/developer-guide/contributing/index.md b/docs/developer-guide/contributing/index.md
@@ -9,9 +9,9 @@ One of the great things about open source projects is that anyone can contribute
 
 This guide is intended for anyone who wants to contribute to an ESLint project. Please read it carefully as it answers a lot of the questions many newcomers have when first working with our projects.
 
-## [Signing the CLA](/cla)
+## [Signing the CLA](https://contribute.jquery.org/cla)
 
-In order to submit code or documentation to an ESLint project, please electronically sign the [Contributor License Agreement](http://eslint.org/cla). The CLA is you giving us permission to use your contribution.
+In order to submit code or documentation to an ESLint project, please electronically sign the [Contributor License Agreement](https://contribute.jquery.org/cla). The CLA is you giving us permission to use your contribution.
 
 ## [Bug Reporting](reporting-bugs)
 

diff --git a/docs/developer-guide/contributing/pull-requests.md b/docs/developer-guide/contributing/pull-requests.md
@@ -10,7 +10,7 @@ If you want to contribute to an ESLint repo, please use a GitHub pull request. T
 
 If you'd like to work on a pull request and you've never submitted code before, follow these steps:
 
-1. Sign our [Contributor License Agreement](/cla).
+1. Sign our [Contributor License Agreement](https://contribute.jquery.org/cla).
 1. Set up a [development environment](../development-environment).
 1. Ensure there's an issue that describes what you're doing. You can create a new issue or just indicate you're [working on an existing issue](working-on-issues).
   * Exception: documentation-only changes do not require an issue.
@@ -71,6 +71,7 @@ The `Tag` is one of the following:
 * `Docs` - changes to documentation only.
 * `Build` - changes to build process only.
 * `Upgrade` - for a dependency upgrade.
+* `Chore` - for refactoring, adding tests, etc. (anything that isn't user-facing).
 
 Use the [labels of the issue you are working on](working-on-issues#issue-labels) to determine the best tag.
 

diff --git a/docs/developer-guide/working-with-rules-new.md b/docs/developer-guide/working-with-rules-new.md
@@ -12,8 +12,8 @@ Each ESLint rule has two files: a source file in the `lib/rules` directory and a
 /**
  * @fileoverview Rule to flag use of an empty block statement
  * @author Nicholas C. Zakas
- * @copyright 2014 Nicholas C. Zakas. All rights reserved.
- * See LICENSE in root directory for full license.
+ * @copyright jQuery Foundation and other contributors, https://jquery.org/
+ * MIT License
  */
 "use strict";
 
@@ -367,8 +367,8 @@ The basic pattern for a rule unit test file is:
 /**
  * @fileoverview Tests for no-with rule.
  * @author Nicholas C. Zakas
- * @copyright 2015 Nicholas C. Zakas. All rights reserved.
- * See LICENSE in root directory for full license.
+ * @copyright jQuery Foundation and other contributors, https://jquery.org/
+ * MIT License
  */
 
 "use strict";

diff --git a/docs/developer-guide/working-with-rules.md b/docs/developer-guide/working-with-rules.md
@@ -12,8 +12,8 @@ Each ESLint rule has two files: a source file in the `lib/rules` directory and a
 /**
  * @fileoverview Rule to flag use of an empty block statement
  * @author Nicholas C. Zakas
- * @copyright 2014 Nicholas C. Zakas. All rights reserved.
- * See LICENSE in root directory for full license.
+ * @copyright jQuery Foundation and other contributors, https://jquery.org/
+ * MIT License
  */
 "use strict";
 
@@ -343,8 +343,8 @@ The basic pattern for a rule unit test file is:
 /**
  * @fileoverview Tests for no-with rule.
  * @author Nicholas C. Zakas
- * @copyright 2015 Nicholas C. Zakas. All rights reserved.
- * See LICENSE in root directory for full license.
+ * @copyright jQuery Foundation and other contributors, https://jquery.org/
+ * MIT License
  */
 
 "use strict";
@@ -560,16 +560,6 @@ The rule naming conventions for ESLint are fairly simple:
 * Keep your rule names as short as possible, use abbreviations where appropriate, and no more than four words.
 * Use dashes between words.
 
-## Rule Acceptance Criteria
-
-Because rules are highly personal (and therefore very contentious), accepted rules should:
-
-* Not be library-specific.
-* Demonstrate a possible issue that can be resolved by rewriting the code.
-* Be general enough so as to apply for a large number of developers.
-* Not be the opposite of an existing rule.
-* Not overlap with an existing rule.
-
 ## Runtime Rules
 
 The thing that makes ESLint different from other linters is the ability to define custom rules at runtime. This is perfect for rules that are specific to your project or company and wouldn't make sense for ESLint to ship with. With runtime rules, you don't have to wait for the next version of ESLint or be disappointed that your rule isn't general enough to apply to the larger JavaScript community, just write your rules and include them at runtime.