docs: Add 2024-10-03 meeting notes

notes/2024/2024-10-03.md

@@ -0,0 +1,87 @@
+# 2024-10-03 ESLint TSC Meeting Notes
+
+## Transcript
+
+[`2024-10-03-transcript.md`](2024-10-03-transcript.md)
+
+## Attending
+
+- Nicholas C. Zakas (@nzakas) - TSC
+- Milos Djermanovic (@mdjermanovic) - TSC
+- Francesco Trotta (@fasttime) - TSC
+
+@nzakas moderated, and @sam3k took notes.
+
+## Topics
+
+### Statuses
+
+* **@mdjermanovic:** I finished support for inline config in @eslint/json
+* **@fasttime:** been busy with https://github.com/eslint/rewrite/pull/59 and reviewing issues and PRs. Also created the [discussion](https://github.com/eslint/eslint/discussions/18957) to help us raise funds and improved on https://github.com/eslint/rfcs/pull/123, neither have received any attention 🙁
+
+
+### RFC Duty Schedule
+
+* September 30: @nzakas
+* October 7: @mdjermanovic
+* October 14: @fasttime
+
+### [Rethinking TypeScript support in ESLint](https://github.com/eslint/eslint/discussions/18830)
+
+Over the past few months, I’ve been having discussions with various folks, including users, plugin developers, and commercial integrators (those who are integrating ESLint into commercial products) about the future of ESLint. One of the most frequently asked questions is, “What are you doing about TypeScript support?” I typically tell them that typescript-eslint is the recommended solution, and the responses ranged from “I already use that and it’s not a smooth experience” to “we can’t use that” (explained more below).
+
+To this point, I’ve been content to tell people to use typescript-eslint and leave it at that, however, some of the more recent conversations have led me to think that our approach may need to change.
+
+**Action Items:** 
+* @mdjermanovic will contribute to the discussion
+
+### [Rule Change: Allow certain whitespace characters when using no-irregular-whitespace](https://github.com/eslint/eslint/issues/18862)
+
+This seems like an edge case that I don't think it makes sense to update the rule for. 
+
+**Resolution:** since no one feels strongly that we need to make an addition we are closing it.
+
+### [Rule Change: [func-style] Allow type-annotated variable declaration](https://github.com/eslint/eslint/issues/18842)
+
+This one asks to change func-style so that a TypeScript function in the form `const foo: Bar = () => {}` will not be flagged when the rule is set to declaration. We want to be careful about adding options for edge cases. We never guarantee a rule will cover everyone's cases, we're just going for the most common 80-90% of cases. In this case, the same effect could be achieved with a function declaration where the types of the arguments and the return type match the expected types of the function type.
+
+**Resolution:** we've agreed to close the issue.
+
+### [Bug: Config array "./src" and "src" aren't treated as the same](https://github.com/eslint/eslint/issues/18757)
+
+The question here is if we should strip `"./"` from the start of patterns in files and ignores.
+
+**Resolution:** we've agreed that `./src` and src should be treated as the same (assuming an acceptable level of complexity for the  implementation)
+
+
+
+## Scheduled release for October 4th, 2024
+
+**Action Items:**
+
+- @fasttime will release the following:
+
+  - `eslint/eslint`
+  - `@eslint/js`
+
+## [Contributor Pool for September 2024](https://github.com/issues?q=org%3Aeslint+label%3A%22contributor+pool%22+merged%3A2024-09-01..2024-09-30)
+
+- @kripod: $500 for:
+  - eslint/eslint#18937
+  - eslint/eslint#18935
+  - eslint/eslint#18932
+  - eslint/eslint#18931
+  - eslint/eslint#18930
+  - eslint/eslint#18929
+  - eslint/eslint#18914
+  - eslint/eslint#18906
+  - eslint/eslint#18905
+  - eslint/eslint#18903
+  - eslint/eslint#18902
+  - eslint/eslint#18901
+  - eslint/eslint#18897
+- @dpashk-figma: $100 for eslint/eslint#18896
+- @Chaedie: $100 for eslint/eslint#18849
+- @brettz9: $100 for eslint/eslint#18836
+- @imjordanxd: $100 for eslint/eslint#18799
+- @RobinTail: $500 for eslint/eslint#18771