Add 2019-11-07 meeting notes (closes #153) (#154)

* Add 2019-11-07 meeting notes (closes #153)

* Fix typo in 2019-11-07 meeting notes

Co-Authored-By: Kevin Partington <platinum.azure@kernelpanicstudios.com>

notes/2019/2019-11-07.md

@@ -0,0 +1,51 @@
+# 2019-November-07 ESLint TSC Meeting Notes
+
+## Transcript
+
+https://gitter.im/eslint/tsc-meetings/archives/2019/11/07
+
+## Attending
+
+* Brandon Mills (@btmills) - TSC
+* Toru Nagashima (@mysticatea) - TSC
+* Kevin Partington (@platinumazure) - TSC
+* Ilya Volodin (@ilyavolodin) - TSC
+
+Additionally, the following individuals are not in attendance but support consensus:
+
+* Nicholas C. Zakas (@nzakas) - TSC
+* Gyandeep Singh (@gyandeeps) - TSC
+
+## Topics
+
+### [New: `ESLint` Class Replacing `CLIEngine`](https://github.com/eslint/rfcs/pull/40)
+
+* @mysticatea hopes to advance this RFC to the Final Commenting stage after this meeting.
+* Per @ilyavolodin, "This is a huge change to the core, so we need to get as much feedback as possible before we decide to go one way or the other."
+* @mysticatea considered using Node.js streams instead of async iterables, but that would require minimum Node.js `v10.17.0`, whereas RFC44 decided on a minimum version of `10.0.0`.
+* Use of async iterables will not preclude adding stream-based APIs in the future.
+* Rather than adding async linting and async plugin loading and deprecating some `CLIEngine` APIs in a single change, an alternative would be an `executeOnFilesAsync` method to support parallel linting and formatters reporting progress.
+* @platinumazure prefers to do everything as a single breaking change to minimize churn for users and maintenance cost compared to a sequence of major API changes.
+* @ilyavolodin wants to enable parallel linting but doesn't see that completely changing ESLint APIs to async buys us enough to justify the effort, especially since the CLI is mostly sync.
+* @mysticatea listed different levels of feature support as a downside of the `executeOnFilesAsync` approach as compared to `executeOnFiles`.
+* As long as `executeOnFilesAsync` produces the same results as `executeOnFiles`, @btmills feels that `executeOnFilesAsync` additionally supporting parallel linting and formatters reporting progress is fine.
+* If we have both sync and async APIs, @mysticatea confirms that RFC45 allows one formatter to support both APIs and gracefully enhance with progress when using the async API.
+* Consensus appears to be that we 1) want to support parallel linting, which 2) requires an async API somewhere, but 3) we want input from @nzakas before we decide where to put that API. :+1: from @platinumazure, @btmills, @mysticatea, @ilyavolodin.
+
+**Resolution**: We want to support parallel linting, but we want input from @nzakas before we decide how to do it.
+
+### [Update: deprecate sourceCode#isSpaceBetweenTokens()](https://github.com/eslint/eslint/pull/12519)
+
+#### TSC Summary
+
+While fixing a bug in in `sourceCode#isSpaceBetweenTokens()`, I noticed that the current documentation is incorrect, also making the name of the method not quite correct.
+
+#### TSC Question
+
+In addition to the bug fix/documentation corrections in #12491, I'd like to propose we deprecate `sourceCode#isSpaceBetweenTokens()` to in favor of `sourceCode#isSpaceBetween()`. This more accurately describes the behavior, as the method currently will check between nodes as well as tokens, and better matches the names of other `sourceCode` methods that check between nodes or tokens.
+
+This PR currently deprecates `sourceCode#isSpaceBetweenTokens()` in a backwards compatible way, having it call through to the new method.
+
+* :+1: from @btmills, @mysticatea, @platinumazure, @ilyavolodin
+
+**Resolution**: Add `sourceCode#isSpaceBetween()` and deprecate `sourceCode#isSpaceBetweenTokens()`.