docs: Add 2025-05-15 meeting notes (#584)

* docs: Add 2025-05-15 meeting notes

* Update notes/2025/2025-05-15.md

* Update notes/2025/2025-05-15.md

---------

Co-authored-by: Milos Djermanovic <[email protected]>

Author: sam3k

notes/2025/2025-05-15.md

@@ -0,0 +1,66 @@
+# 2025-05-15 ESLint TSC Meeting Notes
+
+## Transcript
+
+[`2025-05-15-transcript.md`](2025-05-15-transcript.md)
+
+## Attending
+
+- Nicholas C. Zakas (@nzakas) - TSC
+- Francesco Trotta (@fasttime) - TSC
+- Milos Djermanovic (@mdjermanovic) - TSC
+
+@nzakas moderated, and @sam3k took notes.
+
+## Topics
+
+### Statuses
+
+* **@nzakas:** continuing to refactor the core, bug fixing in CSSTree, and externalizing the MCP server.
+* **@mdjermanovic:** reviewing a lot of PRs.
+* **@fasttime:** fixed some issues with the types and started working on a prototype for multithread linting.
+
+### RFC Duty update:
+
+* May 12 - @fasttime 
+* May 19 - @nzakas
+* May 26 - @mdjermanovic
+
+### Availability Next Week
+* @nzakas expect to have 3 hours each day, outside of May 26, which is a holiday in the US.
+* @mdjermanovic around 2 hours each day.
+* @fasttime expect to be available 2 hours a day the next two weeks
+
+### [feat: Support basePath property in config objects](https://github.com/eslint/rfcs/pull/131)
+
+> @nzakas Because this issue of basePath in extends is the only thing left to resolve, let's go back to @mdjermanovic's original suggestion:
+>
+> To avoid confusion in expectations, defineConfig() should throw an error if it encounters basePath in extended configs?
+>
+> I'm okay with this, as it allows us the opportunity to think through this use case further and make changes down the line if necessary. I think it's important to get this change out relatively soon so we can start v10 planning.
+
+**Resolution:** we've agreed to throw an error when there's `basePath` in `extends`
+
+**Action Items:** team to prioritize updating and approving this RFC.
+
+### [Rule Change: allow expression type annotation in `func-style`](https://github.com/eslint/eslint/issues/19719)
+
+> The `func-style` rule is currently frozen, meaning we aren't making any further changes to it and we'd need the `@eslint/eslint-tsc` to override that. I believe the intent here is to make `func-style` TypeScript-aware, which seems like it goes along with our ongoing work to make ESLint as a whole more TypeScript-aware. As a result, I'm 👍 to overriding the frozen status of this rule for this particular purpose.
+
+**Resolution:** we've agreed to implement this change behind a new option. We've also agreed that updating a frozen rule to support TypeScript syntax makes sense.
+
+**Action Items:** @nzakas will update the description of frozen rules to make that explicit
+
+### Do we want to post release messages in the Discord ⁠announcements channel?
+
+We can automate that along with releasing to social media.
+
+**Resolution:** we've agreed to this.
+
+### Scheduled release for May 16th, 2025
+
+**Action Items:**
+
+- @mdjermanovic will release:
+  - `eslint`
+  - `@eslint/js`