Wording changes

Author: Sashko Stubailo

.github/PULL_REQUEST_TEMPLATE.md

@@ -7,6 +7,7 @@
 
 TODO:
 
+- [ ] If there is a big feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
 - [ ] Make sure all of the significant new logic is covered by tests
 - [ ] Rebase your changes on master so that they can be merged easily
 - [ ] Make sure all tests and linter rules pass

CONTRIBUTING.md

@@ -69,5 +69,5 @@ It’s important that every piece of code in Apollo packages is reviewed by at l
 2. **Simplicity.** Is this the simplest way to achieve the intended goal? If there are too many files, redundant functions, or complex lines of code, suggest a simpler way to do the same thing. In particular, avoid implementing an overly general solution when a simple, small, and pragmatic fix will do.
 3. **Testing.** Do the tests ensure this code won’t break when other stuff changes around it? When it does break, will the tests added help us identify which part of the library has the problem? Did we cover an appropriate set of edge cases? Look at the test coverage report if there is one. Are all significant code paths in the new code exercised at least once?
 4. **No unnecessary changes.** PRs shouldn’t come with random formatting changes, especially in unrelated parts of the code. If there is some refactoring that needs to be done, it should be in a separate PR from a bug fix or feature, if possible.
-5. **Appropriate comments.** Complicated logic should be commented, or written in a clear “self-documenting” way.
+5. **Code has appropriate comments.** Complicated logic should be commented, or written in a clear “self-documenting” way.
 6. **Idiomatic use of the language.** In TypeScript, make sure the typings are specific and correct. In ES2015, make sure to use imports rather than require and const instead of var, etc. Ideally a linter enforces a lot of this, but use your common sense and follow the style of the surrounding code.