diff --git a/notes/2021/2021-01-14.md b/notes/2021/2021-01-14.md
new file mode 100644
index 0000000..00f9eda
--- /dev/null
+++ b/notes/2021/2021-01-14.md
@@ -0,0 +1,74 @@
+# 2021-January-14 ESLint TSC Meeting Notes
+
+## Transcript
+
+[`2021-01-14-transcript.md`](2021-01-14-transcript.md)
+
+## Attending
+
+* Brandon Mills (@btmills) - TSC
+* Toru Nagashima (@mysticatea) - TSC
+* Milos Djermanovic (@mdjermanovic) - TSC
+* Nicholas C. Zakas (@nzakas) - TSC
+
+@nzakas moderated, and @btmills took notes and updated issues with resolutions.
+
+## Topics
+
+### [TSC/reviewer payment structure](https://github.com/eslint/tsc-meetings/issues/232#issuecomment-759768291)
+
+> @nzakas: I'd like to review the TSC/reviewer payment structure we have and see what people think now that we've been paying people for just about a year. I'm mostly interested in the limits: does the 20 hour per month limit still make sense? Does $50/hour still make sense? Is there anything we want to tweak at this point?
+
+* @nzakas has not come close to the limit. @mdjermanovic typically spends 35-40hr. @btmills usually hits around 20hr. @mysticatea hasn't had much time.
+* The limit was originally to prevent burnout, and the $50/hr rate was what Webpack was paying and seems to be the going rate for frontend contract work.
+* @nzakas likes to keep the hour limit even if it's more a reminder than a hard cap but feels uncomfortable that @mdjermanovic has been doing double the work unpaid and proposes keeping $50/hr up to 20hr/mo and adding $25/hr over 20hr/mo. :+1: from @btmills, @mdjermanovic, and @mysticatea.
+* Should we have a hard limit at 40 total hours per month? That would help calculating budget reserves. @mdjermanovic could work more some months but is fine with a limit. @nzakas proposes starting with a 40hr/mo cap and revisiting in a few months. :+1: from @btmills, @mdjermanovic, and @mysticatea.
+
+**Resolution**: We will pay $25/hr for hours 21-40 each month and revisit in a few months. @nzakas will update the team repository.
+
+### [Process](https://github.com/eslint/tsc-meetings/issues/232#issuecomment-759768291)
+
+> @nzakas: What parts of our process are slowing/breaking down right now? It seems that everyone isn't around as much as previously, so it might be a good time to talk about how that's affecting the project.
+
+* @nzakas hasn't been able to do as much lately but is hoping that will change soon.
+* @btmills feels like we're back where we were before we had a half-time maintainer. Latency has increased, and issues/PRs past the first page get less activity.
+* @nzakas agrees and feels the logjam is when issues/PRs are opened and that PRs are still getting merged. The project board would help here.
+* @btmills agrees that the beginning of the funnel is the slow part, and the release cycle acts to keep merges moving.
+* @nzakas plans to finish up the [project board](https://github.com/eslint/tsc-meetings/blob/5a1f2107149119453b61d499a3cfeef34f8df712/notes/2020/2020-10-08.md#project-to-track-issue-triage) and setting up a [triage team](https://github.com/eslint/tsc-meetings/blob/5a1f2107149119453b61d499a3cfeef34f8df712/notes/2020/2020-09-24.md#triage-team) to help.
+* @btmills suggests offering existing committers to formalize an hourly rate on the triage team, and @nzakas suggests "promoting" repeat contributor award recipients.
+* :+1: from @mdjermanovic, @btmills, and @mysticatea.
+
+**Resolution**: @nzakas will prioritize finishing the project board and then follow up with a propsal for starting the triage team.
+
+### [Lock files](https://github.com/eslint/tsc-meetings/issues/232#issuecomment-759865391)
+
+> @nzakas: let’s talk about why we don’t use lock files in the repos and whether it makes sense.
+
+* Lock files are most useful for deployed applications to ensure versions are consistent between environments and across deployments.
+* We could use a lock file to keep versions consistent in our development environments.
+* End-user installs via `npm install eslint` or `yarn add eslint` do not use dependencies' lock files, so CI shouldn't lock versions either with `npm ci`.
+* If we were to use `package-lock.json` and one of our dependencies accidentally breaks in a newer version, end users would see the issue, and CI could reproduce it, but we'd have to update our lock file to reproduce it locally.
+* @nzakas suggests publishing this reasoning as a README FAQ. @btmills suggests linking to https://www.twilio.com/blog/lockfiles-nodejs.
+
+**Resolution**: @btmills will add a README FAQ explaining why we don't use a lock file.
+
+### [TC39 tools outreach meetings](https://github.com/eslint/tsc-meetings/issues/232#issuecomment-760440650)
+
+> @btmills: I've been attending monthly TC39 tools outreach discussions for about a year now. The time commitment is about 2 hours between pre-reading discussion topics, the meeting itself, and sending out notes to our team.
+>
+> - Should we continue having a team member attend?
+> - Would anyone else like to do some? (Not saying I don't want to - it's interesting - just making sure I'm not excluding someone else who's interested.)
+> - Is the notes format sufficient? Can I improve anything?
+
+* @nzakas feels it's important to be there, would like to go at some point, and enjoys the notes.
+* @mdjermanovic says the notes are great.
+* @btmills finds attending beneficial persionally for education and for the project when topics are relevant to ESLint. It gives advance notice of future language changes and a chance to help inform designs that affect ESLint.
+
+**Resolution**: Attendance is worthwhile, @btmills will continue going, and @nzakas hopes to attend in the future.
+
+### [Scheduled release for January 15th, 2021](https://github.com/eslint/eslint/issues/13982)
+
+* Jenkins is up, and it appears that @nzakas fixed the permissions error.
+* Team members should add public keys to GitHub so @nzakas can add them to the Jenkins server.
+
+**Resolution**: @mdjermanovic will do the release.