diff --git a/notes/2020/2020-07-16.md b/notes/2020/2020-07-16.md
new file mode 100644
index 0000000..1383131
--- /dev/null
+++ b/notes/2020/2020-07-16.md
@@ -0,0 +1,82 @@
+# 2020-July-16 ESLint TSC Meeting Notes
+
+## Transcript
+
+[`2020-07-16-transcript.md`](2020-07-16-transcript.md)
+
+## Attending
+
+* Nicholas C. Zakas (@nzakas) - TSC
+* Milos Djermanovic (@mdjervanovic) - TSC
+* Brandon Mills (@btmills) - TSC
+* Kai Cataldo (@kaicataldo) - TSC
+* Toru Nagashima (@mysticatea) - TSC
+
+@nzakas moderated, and @btmills took notes and updated issues with resolutions.
+
+## Topics
+
+### [[no-void]: allow void arrow functions](https://github.com/eslint/eslint/issues/13299)
+
+* **TSC Summary:** The proposal here is to add a new option to `no-void` that will allow the form `() => void foo;`, which currently emits a warning. Our policy says [we have frozen stylistic rules](https://eslint.org/blog/2020/05/changes-to-rules-policies#what-are-the-changes) and there are other ways to accomplish the same thing (creating a custom rule, using `no-restricted-syntax`, etc.).
+* **TSC Question:** Should we accept this proposal?
+* @btmills is in favor of closing the issue given @mdjervanovic's [`no-restricted-syntax` alternative](https://github.com/eslint/eslint/issues/13299#issuecomment-656335560).
+* @mdjermanovic thinks `no-void` is improperly categorized as a Best Practice.
+* @nzakas thinks that `no-void` was copied over from JSCS and added to Best Practices for compatibility reasons.
+* @kaicataldo agrees with @mdjermanovic and @btmills.
+* @mdjermanovic suggests re-categorizing as a Stylistic rule. @btmills agrees. @kaicataldo agrees and suggests a new issue for that.
+* @nzakas summarizes consensus as not wanting to accept the new option and instead re-categorizing `no-void` as a Stylistic rule. :+1: from @kaicataldo, @btmills, and @mdjermanovic.
+
+**Resolution**: We will not accept the new `no-void` option, and @mdjermanovic will open an issue to reclassify it as a Stylistic rule.
+
+### [Closing old config RFCs](https://github.com/eslint/tsc-meetings/issues/187#issuecomment-658398121)
+
+* @nzakas: Now that https://github.com/eslint/rfcs/pull/9 has been merged, I'd like to suggest we close https://github.com/eslint/rfcs/pull/5, https://github.com/eslint/rfcs/pull/14, https://github.com/eslint/rfcs/pull/21, and https://github.com/eslint/rfcs/pull/54. These all have to do with changing how configuration works, and given that we're heading in a new direction, it seems that we should be able to close these.
+* :+1: from @btmills, @kaicataldo, and @mdjermanovic.
+* @mysticatea joins the chat and adds :+1: for closing in favor of the new direction.
+
+**Resolution**: @btmills will close the remaining config-related RFCs.
+
+### [Consolidating parallel linting RFCs](https://github.com/eslint/tsc-meetings/issues/187#issuecomment-658398121)
+
+* @nzakas: There are several RFCs for parallel linting: https://github.com/eslint/rfcs/pull/4, https://github.com/eslint/rfcs/pull/11, and https://github.com/eslint/rfcs/pull/42. None of these take into account the new configuration system or the `ESLint` class. As https://github.com/eslint/rfcs/pull/42 is the most recent, we could decide to leave that open and close the others, or close all three depending on @mysticatea's interest in updating his RFC.
+* @btmills is :+1: to closing the first two and defers to @mysticatea whether to continue the third or close and start fresh.
+* :+1: from @kaicataldo, @nzakas, and @mdjermanovic.
+* @mysticatea has a [prototype](https://github.com/eslint/eslint/tree/very-rough-worker-threads-poc/lib/eslint) built around the `ESLint` class.
+* @nzakas proposes closing the first two RFCS and @mysticatea updating the third to reflect the prototype. :+1: from @btmills, @mysticatea, @kaicataldo, and @mdjermanovic.
+
+**Resolution**: @btmills will close the first two RFCs, and @mysticatea will update the third to reflect the prototype.
+
+### [Scheduled release for July 17th, 2020](https://github.com/eslint/eslint/issues/13470)
+
+* @btmills suggests that @mdjermanovic should shadow one of the other TSC members on a release to become familiar with the process.
+* @kaicataldo volunteers to run the release.
+* @kaicataldo asks what work remains on [Update: optional chaining support (fixes #12642)](https://github.com/eslint/eslint/pull/13416).
+* @mdjermanovic believes it's ready, and @mysticatea says we just need to release `espree` and update `package.json`.
+* @kaicataldo will review the pull request and handle the `espree` upgrade as part of the release.
+* @nzakas requests batching large changes in groups of 10-20 rules per pull request.
+
+**Resolution**: @kaicataldo will release `espree` and `eslint`.
+
+### [`fixable` property only necessary when `meta` is present](https://github.com/eslint/eslint/issues/13349)
+
+* @mdjermanovic asks for confirmation that [@nzakas's comment](https://github.com/eslint/eslint/issues/13349#issuecomment-646729029) would intentionally disable fixing for old-style rules.
+* @nzakas confirms and explains that the idea is to make the change in `RuleTester` first to give plugin authors a heads up before disabling fixing for legacy rules as a breaking change in a future major release.
+* :+1: from @mdjermanovic.
+
+### Hiring a community manager
+
+* @nzakas: We discussed in the chat last week about potentially hiring a community manager who's primary job would be to triage issues and pull requests, and to help answer questions in Discord and maybe on Twitter. The idea is to pay someone $25/hour up to 10 hours each week (minimum of 3). Since we are chronically behind in responding to issues, this seems like a way to give us some breathing room. A couple people said they were in favor, but wanted to bring it up here to get everyone's opinion.
+* :+1: from @kaicataldo, @btmills, @mdjermanovic, and @mysticatea.
+* @nzakas: Okay cool. So the tricky part is we'd need to get a signed agreement to do that, but ESLint isn't a legal entity, so we can't do that ourselves. I have a meeting next week with Open JS Foundation to discuss our options. As I mentioned in the chat, the worst case scenario is that I can do it under my LLC, though I think it would be better for everyone if it was under the Foundation. I'll let you know what happens.
+
+**Resolution**: @nzakas will take the lead on figuring out how to hire a community manager.
+
+### Using the `team` repository
+
+* @nzakas wants to start using the existing `team` repository to document our processes and keep track of tasks that don't belong in other repositories. This could include, for instance, issues to request creating a new repository under the organization, issue templates for on-boarding new team members, and documenting troubleshooting for Jenkins and npm token issues. We could make it public or keep it private to the team.
+* @btmills asks if this would take the place of mailing list discussions like nominating new team members.
+* @nzakas would keep sensitive discussions like nominations on the mailing list, but the rest could migrate over.
+* :+1: from @kaicataldo, @btmills, @mysticatea, and @mdjermanovic.
+
+**Resolution**: @nzakas will set up the `team` repository with some initial documentation.