Add 2016-11-10 meeting notes (closes #17)

notes/2016/2016-11-10.md

@@ -0,0 +1,68 @@
+# 10-Nov-2016 ESLint TSC Meeting Notes
+
+## Transcript
+
+https://gitter.im/eslint/tsc-meetings/archives/2016/11/10
+
+## Attending
+
+* Nicholas Zakas (@nzakas) - TSC
+* Gyandeep Singh (@gyandeeps) - TSC
+* alberto (@alberto) - TSC
+* Toru Nagashima (@mysticatea) - TSC
+* Ilya Volodin (@ilyavolodin) - TSC
+* Brandon Mills (@btmills) - TSC
+* Kai Cataldo (@kaicataldo) - TSC
+
+## Topics
+
+### [Autofixing no-plus-plus](https://github.com/eslint/eslint/pull/7514)
+
+* TSC Summary: This PR proposes to autofix the no-plus-plus rule by replacing `i++` with `i += 1` and `i--` with `i -= 1`. My feeling is that we shouldn't be doing this autofix do the locations where `i++` can be used and the fact that we don't know 100% what the preferred replacement for everyone should be. The counterargument is that we can do autofixes in some places with reasonable accuracy and `+=` and `-=` might be okay for most developers.
+* TSC Question: Do we want to autofix this rule?
+* It's difficult to discern what a user _does_ want in this case, so autofixing could be harmful.
+* This would be safer if the user could explicitly opt into autofixing `no-plus-plus`.
+
+**Resolution**: We won't add autofixing to `no-plus-plus` as long as we don't have per-rule autofix settings.
+
+### [Rule Proposal: require-await](https://github.com/eslint/eslint/issues/6820)
+
+* TSC Summary: The require-await rule enforces that async functions always contain await. It has a champion and three :+1:s as well as two :-1:s from the team. The argument against is that there are valid use cases for using async functions without await, so the rule might not be applicable in all situations. The argument for is that this rule is similar to require-yield for generator functions in that it seems more likely people will want to use await with async functions than not, and those who disagree can disable the rule.
+* TSC Question: Shall we accept this rule?
+* Questions regarding the best categorization for this rule if it were to be accepted. "Possible errors" seems too strong, and there's debate about it being a "best practice" as well.
+* :+1: from @mysticatea, @gyandeeps, @alberto, @nzakas
+* :-1: from @kaicataldo, @btmills, @ilyavolodin
+
+**Resolution**: The rule will be included in core.
+
+### [Warn on deprecated rules](https://github.com/eslint/eslint/issues/7443)
+
+* TSC Summary: We currently support warnings for rules that have been outright removed (and only core rules). Now that we have meta.deprecated, users may wish to see that a core or plugin rule has been deprecated.
+* TSC Question: Should we augment ESLint core to generate a warning message when rules are deprecated? If so, should we support more metadata fields to allow rule maintainers to indicate the upgrade path and/or removal timeline?
+* :+1: from @ilyavolodin, @btmills, @kaicataldo, @mysticatea
+
+**Resolution**: This feature will be added to core. Implementation will continue to be discussed in the issue.
+
+### [Allow setting ecmaVersion to latest](https://github.com/eslint/eslint/issues/7528)
+
+* TSC Summary: The proposal is to add `ecmaVersion: latest`, which would always point to the highest available ECMAScript version ESLint supports. The team does not feel that ESLint should automatically pull in the highest Espree ECMAScript version supported because an Espree release could opaquely affect existing ESLint versions. The team feels that you could hardcode `"latest"` to a specific ECMAScript version and update it periodically. Some think this update must be done in a major version, others suggest doing so in a minor version.
+* TSC Questions: 1) Are we in favor of having `ecmaVersion: latest` and 2) if yes, would we want to update the value of latest in a major version or a minor version?
+* General ambivalence about the feature and its value, but agreement that incrementing a hypothetical `latest` value would have to be done in a major release.
+* Nobody argues in favor of inclusion.
+
+**Resolution**: This feature will not be added.
+
+### Assign [upcoming](https://github.com/eslint/eslint/issues/7512) [releases](https://github.com/eslint/eslint/issues/7577)
+
+**Resolution**: @ilyavolodin and @btmills will do the 2016-11-11 release, and @btmills and @nzakas will do the 2016-11-25 release.
+
+### [Issue/PR triaging process](https://github.com/eslint/tsc-meetings/issues/22#issuecomment-259523728)
+
+* I'd like to spend some time talking about the issue/PR triaging process. It seems like we are really struggling to keep up with the incoming issues and PRs, and I'd like to talk through that a bit to see if we can figure out ways to improve the process.
+* Core team is busy for various reasons. @vitorbal, @platinumazure, and @not-an-aardvark are doing a great job keeping things moving.
+* Want to reiterate that [anyone on the team](https://github.com/eslint/tsc-meetings/blob/master/notes/2016/2016-10-13.md#relaxing-rules-for-who-can-merge-prs) can merge PRs with at least one approval from TSC.
+* Holdup mostly seems to be with code review.
+* @nzakas proposes that TSC prioritizes reviewing PRs before issues.
+* :+1: from @btmills, @ilyavolodin, @kaicataldo, @gyandeeps, @mysticatea, @alberto
+
+**Resolution**: 1) Reiterate to the team that PRs with at least one TSC member approval can be merged by anyone. 2) TSC members will now prioritize PR reviews over issue reviews.