Add 2019-08-29 meeting notes (closes #146) (#147)

notes/2019/2019-08-29.md

@@ -0,0 +1,89 @@
+# 2019-August-29 ESLint TSC Meeting Notes
+
+## Transcript
+
+https://gitter.im/eslint/tsc-meetings/archives/2019/08/29
+
+## Attending
+
+* Brandon Mills (@btmills) - TSC
+* Toru Nagashima (@mysticatea) - TSC
+* Ilya Volodin (@ilyavolodin) - TSC
+* Kevin Partington (@platinumazure) - TSC
+* Kai Cataldo (@kaicataldo) - TSC
+
+Additionally, the following individuals are not in attendance but support consensus:
+
+* Nicholas C. Zakas (@nzakas) - TSC
+* Gyandeep Singh (@gyandeeps) - TSC
+
+## Topics
+
+### [Add CodeTriage badge to eslint/eslint](https://github.com/eslint/eslint/pull/11807)
+
+* This has come up in the last two meetings and was postponed with a request for more information.
+* @btmills suggests that we should close it because nobody seems excited enough to dig in more. :+1: from @ilyavolodin, @platinumazure, @mysticatea.
+
+**Resolution**: Close the pull request.
+
+### [[Trial] add static type validation to our codebase](https://github.com/eslint/eslint/pull/12082)
+
+#### TSC Summary
+
+This PR adds a new static analysis, to check the types of JSDoc, to the source code of core rules. The static analysis will find the overlooks to handle AST properly, then fail tests.
+
+**Pros:**
+
+- Contributors can notice the edge cases of AST handling. (for example, 3/8 core rules in alphabet order have overlooked the literal property names.)
+- Reviewers can focus on what the rule does rather than whether the rule handles AST properly or not.
+- Popular editors can provide proper input completion and popup documents when people implement rules.
+
+**Cons:**
+
+- Contributors need knowledge about JSDoc notations and TypeScript type notations.
+- The static analysis has false positive due to the limitation of the static type checking. For example, the static analysis says `sourceCode.getTokenAfter(token)` can return `null` even if never returns `null` in the situation.
+- We need much work to add the static analysis to every core rule.
+
+#### TSC Question
+
+Should we go to this direction?
+
+* How much of a benefit is this relative to the cost of augmenting the codebase with type annotations?
+* The `require-jsdoc` and `valid-jsdoc` rules give us a head start, but some would have to be modified to be correct.
+* Using JSDoc type annotations would help if we later decided to move the codebase to TypeScript.
+* The team generally agrees that adding types would likely catch bugs in a decent portion of rules.
+* We've dramatically reduced the incidence of crashing bugs over the last few years. @ilyavolodin believes the lack of bug reports over our large user base means the remaining bugs are likely to be edge cases.
+* @mysticatea feels types will help as new JS versions gain new syntax.
+* @platinumazure would like to see the results of adding type checking to more rules before making a decision, provided @mysticatea is willing and nobody feels likely to oppose it at this point. :+1: from @ilyavolodin, @btmills, @mysticatea
+
+**Resolution**: @mysticatea will do more research.
+
+### [Chore: use GitHub Actions](https://github.com/eslint/eslint/pull/12144)
+
+#### TSC Summary
+
+This PR switches our CI to GitHub Actions from Azure Pipelines.
+
+**Pros:**
+
+- We don't need to depend on external services for CI.
+- I guess that we can aggregate CI and other workflows (commit message validator, release cycle monitor, "needs info" label handler, and auto-closer of issues) into GitHub Actions. If it was realized, probably we can reduce the maintenance cost of infrastructure.
+
+**Cons:**
+
+- It's still beta.
+- It doesn't provide the detail of tests. (E.g., Azure Pipelines provide the [Tests Tab](https://dev.azure.com/eslint/eslint/_build/results?buildId=341&view=ms.vss-test-web.build-test-results-tab))
+- It doesn't provide the detail of code coverage. (E.g., Azure Pipelines provide the [Code Coverage Tab](https://dev.azure.com/eslint/eslint/_build/results?buildId=341&view=codecoverage-tab))
+
+#### TSC Question
+
+Should we switch CI?
+
+* @ilyavolodin, @platinumazure, and @btmills feel GitHub Actions is early and not quite ready yet.
+* @btmills suggests merging this without removing our existing CI to gain experience with Actions without completely depending on them. :+1: from @ilyavolodin and @mysticatea. :+1: from @kaicataldo on the pull request outside the meeting. @platinumazure supports consensus.
+
+**Resolution**: Add GitHub actions without replacing the existing infrastructure.
+
+### [Scheduled release for August 30th, 2019](https://github.com/eslint/eslint/issues/12159)
+
+**Resolution**: @ilyavolodin and @platinumazure will do the release.