Add 2016-10-13 meeting notes (closes #16)

notes/2016/2016-10-13.md

@@ -0,0 +1,60 @@
+# 13-Oct-2016 ESLint TSC Meeting Notes
+
+## Transcript
+
+https://gitter.im/eslint/tsc-meetings/archives/2016/10/13
+
+## Attending
+
+* Nicholas Zakas (@nzakas) - TSC
+* Toru Nagashima (@mysticatea) - TSC
+* alberto (@alberto) - TSC
+* Kai Cataldo (@kaicataldo) - TSC
+* Brandon Mills (@btmills) - TSC
+* Gyandeep Singh (@gyandeeps) - TSC
+* Ilya Volodin (@ilyavolodin) - TSC
+
+## Topics
+
+### [Relaxing rules for who can merge PRs](https://github.com/eslint/tsc-meetings/issues/16#issuecomment-252755224)
+
+* I'd like to propose that we allow any team member to merge non-breaking PRs so long as at least one TSC member has approved the PR and the waiting period has passed.
+* If a TSC member has already approved a PR and is just waiting the 2-3 days for others to review, it doesn't really make sense to prevent committers from merging the PR after that point since the TSC member would likely have done it anyway. This could help ensure that PRs are landed faster because it expands the pool of people who can merge. Currently, committers cannot merge PRs other than chores, bug fixes, and documentation changes.
+* :+1: from @alberto, @kaicataldo, @btmills, @mysticatea
+
+**Resolution**: Any team members can merge a PR provided that at least one TSC member has approved and the issue is past the waiting period. We will update the maintainer guide to reflect this resolution.
+
+### Review accepting pull requests without issues
+
+* Above agenda item ought to help with some of the backlog.
+* Having high level discussion of core changes in issues separate from technical discussion in PRs is working well.
+* The three checkbox for "I've read the contribution guidelines", "add docs", and "added tests" doesn't seem like it's helping anything.
+
+**Resolution**: Those three checkboxes in the PR template will be changed to a comment.
+
+### [ESLint fork of escope](https://github.com/eslint/tsc-meetings/issues/16#issuecomment-251245605)
+
+* I'd like to discuss creating an ESLint fork of escope. We've talked about this for a while behind-the-scenes, and I think it's time for us to make a decision.
+* Currently escope is not actively maintained, and it doesn't seem like asks for custom functionality are going to be accepted. Rather than continuing to fight about things we might need to support TypeScript or other functionality, I think it's time to consider forked escope for use within ESLint.
+* `babel-eslint` current reaches into the file system and monkey patches escope to support node types we don't know or understand. This would be a breaking change, as we'd have to give babel-eslint a heads up to avoid breaking those users.
+* :+1: from @gyandeeps, @mysticatea, @alberto, @kaicataldo
+
+**Resolution**: Fork `escope` and work with `babel-eslint` to include the fork in v4.0.0.
+
+### https://github.com/eslint/eslint/issues/7235
+
+* The request is to make func-names not warn when a function's name property has a non-empty string value in ES6. This would be behind an option.
+* @nzakas objected because that seems like a different purpose than the original rule.
+* @ilyavolodin and @btmills see the rule as ensuring names are present for debugging.
+
+**Resolution**: The enhancement will be accepted and the documentation needs to be updated to better describe the purpose of the rule.
+
+### https://github.com/eslint/eslint/issues/7230
+
+* This is a request for a `prefer-object-spread` rule or an enhancement to `prefer-spread` to suggest object spread in addition to array spread.
+* The contention is that instead of using `Object.assign`, we should suggest using object spread properties.
+* Syntax is currently stage 3.
+* An option on `prefer-spread` is preferred to a new `prefer-object-spread` rule.
+* Its utility doesn't seem to meet the bar for inclusion.
+
+**Resolution**: The proposal doesn't meet the bar for inclusion.