diff --git a/notes/2019/2019-10-10.md b/notes/2019/2019-10-10.md
new file mode 100644
index 0000000..521e6e6
--- /dev/null
+++ b/notes/2019/2019-10-10.md
@@ -0,0 +1,78 @@
+# 2019-October-10 ESLint TSC Meeting Notes
+
+## Transcript
+
+https://gitter.im/eslint/tsc-meetings/archives/2019/10/10
+
+## Attending
+
+* Brandon Mills (@btmills) - TSC
+* Toru Nagashima (@mysticatea) - TSC
+* Ilya Volodin (@ilyavolodin) - TSC
+* Kevin Partington (@platinumazure) - TSC
+
+Additionally, the following individuals are not in attendance but support consensus:
+
+* Nicholas C. Zakas (@nzakas) - TSC
+* Gyandeep Singh (@gyandeeps) - TSC
+
+## Topics
+
+### [require-atomic-updates false positive](https://github.com/eslint/eslint/issues/11899)
+
+* **TSC Summary**: `require-atomic-updates` is currently on in `eslint:recommended` and appears to be flagging safe code (see examples in comments above). 
+* **TSC Question**: Can we remove this rule from `eslint:recommended` while we decide how we want to move forward with the rule? This should be fine to do in a semver-minor release because it will result in fewer errors being reported.
+* @platinumazure points out that currently our [semantic versioning policy](https://github.com/eslint/eslint#semantic-versioning-policy) states that changes to `eslint:recommended` are semver-major.
+* When that policy was written, it plausibly had in mind adding new rules and changing configurations that would make `eslint:recommended` more strict. This change, if accepted, would make `eslint:recommended` less strict. We could update the policy so that changes that relax `eslint:recommended` could be semver-minor or -patch.
+* @platinumazure, @btmills, @ilyavolodin, and @mysticatea are all in favor of making `eslint:recommended` relaxations semver-minor.
+* :+1: to changing the versioning policy and removing `require-atomic-updates` from `eslint:recommended` from @mysticatea, @btmills, @platinumazure, and @ilyavolodin.
+
+**Resolution**: Update the semantic versioning policy to allow relaxing `eslint:recommended` in a semver-minor release and remove `require-atomic-updates` from `eslint:recommended`.
+
+### [Release schedule](https://github.com/eslint/tsc-meetings/issues/149#issuecomment-530990434)
+
+* **TSC Description**: We have only 5 people active members of TSC currently, and we've lately been having a lot of trouble with finding available people to do releases every two weeks. We skipped number of releases in the summer due to the lack of availability. I propose that we either have to switch back to requiring only one person to do a release, or increase time between releases to once a month.
+* **TSC Question**: Should we accept this proposal. And if so, which one?
+* @platinumazure and @ilyavolodin prefer having two developers available for a release to check each other's work and debug together if something breaks.
+* @platinumazure suggests single-developer releases might be easier if we merged more PRs in between releases rather than immediately before. However, we lack a way to enforce that.
+* @mysticatea prefers not to reduce release frequency because that could increase the number of PRs the release participants need to review. Releases can already take 1.5-3 hours.
+* @platinumazure suggests somehow timeboxing releases.
+* @mysticatea suggests canary builds that are released each time we merge to master as a way of reducing load on the release team. @btmills points out that people don't often use betas and release candidates of major versions. @platinumazure points out that those require migration work, whereas canaries wouldn't.
+* @ilyavolodin suggests using TSC meeting time to review PRs as a group.
+* :+1: to trying a 4-week release cycle and reviewing PRs during biweekly TSC meetings until the end of the year from @ilyavolodin, @btmills, @platinumazure. @mysticatea wants to include canaries if we move to a 4-week release cycle.
+* No opposition to canary releases.
+* @platinumazure notes that we will need to update the bot and README for the 4-week release cycle.
+
+**Resolution**: Until the end of the year, trial a 4-week release cycle and using TSC meetings to review PRs between releases. Add canary releases automatically after merging to master.
+
+### [ESLint v7 schedule](https://github.com/eslint/tsc-meetings/issues/149#issuecomment-538721777)
+
+**TSC Description**:
+
+Let's discuss to schedule for the ESLint `7.0.0` release. I have a rough draft:
+
+- 2019-11-08 ... Start to discuss we should include what changes into `7.0.0`.
+- 2019-12-05 ... Feature-freeze. After this release cycle, start to merge breaking change PRs.
+- 2020-01-31 ... Stable release.
+
+The following items are the reason I'm thinking it's good timing:
+
+- In December 2019, Node.js 8.x will be EOL (https://github.com/nodejs/Release#release-schedule). We can drop supports for that then start to use async iteration ([RFC40](https://github.com/eslint/rfcs/pull/40) may use async iteration).
+- We have a ton of issues/PRs that are breaking changes (https://github.com/eslint/eslint/projects/6)
+- The `1.0.0` release was 31 July 2015 and the `1.10.3` release was 1 December 2015. Since the `6.0.0` release was 21 June 2019, so the `6.x` duration in the draft plan is longer than the `1.x` duration (and the `2.x` duration also). Therefore, from the precedent, we have enough intervals for the new major release.
+
+**TSC Question**:
+
+How should we schedule to release ESLint `7.0.0`?
+
+* We have no reason to rush, but there's also plenty of changes to justify beginning work on v7. As long as we wait for Node 8.x EOL, anytime after that works.
+* @btmills proposes following the schedule as suggested above and letting it slip if we miss a TSC meeting or release.
+* :+1: from @platinumazure, @ilyavolodin, @mysticatea
+
+**Resolution**: The proposal is accepted.
+
+### [Scheduled release for October 11th, 2019](https://github.com/eslint/eslint/issues/12362)
+
+* Nobody is available concurrently, so @btmills proposes starting 4-week release cycles by skipping this weekend's release and reviewing PR's in the next TSC meeting. :+1: from @ilyavolodin, @platinumazure, @mysticatea.
+
+**Resolution**: We will not do a release on October 11th. We will review PRs in the TSC meeting on October 24th and do the next release on October 25th.