Add notes from Dec WG (#1613)

Author: benjie

.gitignore

@@ -1 +1,2 @@
+.git/
 node_modules/

notes/2024/2024-12.md

@@ -0,0 +1,166 @@
+# GraphQL WG Notes - December 2024
+
+**Watch the replays:**
+[GraphQL Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foH30_sDnEZnxV_8pYW3SDtb)
+
+Agenda:
+[https://github.com/graphql/graphql-wg/blob/main/agendas/2024/12-Dec/05-wg-primary.md](https://github.com/graphql/graphql-wg/blob/main/agendas/2024/12-Dec/05-wg-primary.md)
+
+1. Agree to Membership Agreement, Participation & Contribution Guidelines and
+   Code of Conduct (1m, Host)
+   - [Specification Membership Agreement](https://github.com/graphql/foundation)
+   - [Participation Guidelines](https://github.com/graphql/graphql-wg#participation-guidelines)
+   - [Contribution Guide](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md)
+   - [Code of Conduct](https://github.com/graphql/foundation/blob/master/CODE-OF-CONDUCT.md)
+2. Introduction of attendees (5m, Host)
+3. Determine volunteers for note taking (1m, Host)
+4. Review agenda (2m, Host)
+5. Check
+   for[ ready for review agenda items](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc)
+   (5m, Host)
+6. [Move January meeting to Jan 9?](https://github.com/graphql/graphql-wg/pull/1595)
+   (1m, Benjie)
+   - Group agreed
+7. TSC membership vote - open for nominations (2m, Host)
+   - [Election process](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md#election-process)
+   - Anyone can self-nominate or nominate others
+   - Lee to open the nomination form and share out
+   - Andy, Kewei, Rob, Stephen, Uri’s terms are set to end (re-nomination is of
+     course open to them)
+8. Add 'extensions' to request (2m, Benjie)
+   - [RFC](https://github.com/graphql/graphql-spec/pull/976) - promote to RFC 2?
+     (Does it actually _need_ any code changes?)
+   - Benjie: Not really meaningful to spec - reserve space for tools/vendors to
+     extend
+   - Adds a challenge RE: various transports - defining it over and over again
+   - Proposing (a) advance to RFC2 (b) acknowledge no code changes needed
+   - Lee: seems like a slam-dunk change
+9. Make `deprecated.reason` non-null (5m, Martin)
+   - spec
+     edits:[ graphql/graphql-spec#1040](https://github.com/graphql/graphql-spec/pull/1040)
+   - graphql-js pull
+     request:[ graphql/graphql-js#4299 (review)](https://github.com/graphql/graphql-js/pull/4299#pullrequestreview-2455415595)
+   - Martin: Did a PR to graphql-js
+   - That’s all I have
+   - Lee: repeating back, it sounds like since we’re saying that because
+     `reason` has a default value, we should disallow the ability to use
+     `null`-literal as a value, which is technically possible if `reason` is
+     nullable
+   - Matt: not possible to send a request with deprecated from clients, yes?
+   - Lee: should only impact tooling
+   - Lee: approved and merging - awaiting graphql-js maintainers
+10. Add a validation rule that operation types exist (5m, Benjie)
+    - [RFC](https://github.com/graphql/graphql-spec/pull/955) - promote to RFC
+      2?
+    - Proposal to add a new validation rule - does an operation type exist
+    - Lee: agreed, suggests moving to “accepted”
+    - Lee: will do offline review, want to accept and merge
+    -
+11. Change 'original' to 'previous' to clarify multiple extensions (5m, Benjie)
+    - [RFC](https://github.com/graphql/graphql-spec/pull/1123) - editorial;
+      merge?
+    - Benjie: When extending types, we use the term “original” but we allow for
+      multiple extensions. This can be confusing.
+      - This allows for something invalid:
+        1. union MyUnion = Foo
+        2. extend union MyUnion = Bar | Baz
+        3. extend union MyUnion = Bar | Qux
+    - Let’s wait 2 weeks and then we can merge
+12. GraphQL-JS maintenance (10m, Jovi)
+    - Who has access to Netlify and how can we disconnect it
+      - Nobody knows on the call
+      - Maybe Ivan?
+      - Uri says he might have access 🎉
+    - What are our expectations of GraphQL.JS (frequency of publishing, docs,
+      ...)
+      - We’ve never declared LTS/EOL stuff
+      - In practice, we’ve generally put our energy into new versions
+      - Have we backported releases to prior majors?
+      - Yes, recently with introspection fix
+      - Lee: open to any reasonable proposal here
+      - Matt: one bare minimum is when we switched from Flow to TS
+      - Lenz: adding some concern to that - GraphQL versions can tend to take a
+        long time - maybe majors released in the last two years - plenty of time
+        to migrate over - could also be another time frame
+      - Gives people some security
+      - Jovi: for clarity, in our case, v16 would be immediately dropped
+      - Lee: something like adding a time window
+    - When do we want v17
+      - Jovi: Several specs ongoing
+      - Rob: defer/stream in v17 - not exposed by regular execution function
+      - If we were to release v17, we would not open up defer/stream - still
+        experimental in that release
+      - Yaacov: to clarify that post - where do we need to be in terms of our
+        approval process to defer/stream to release v17?
+      - Implicit in your answer, Rob, is that we could be anywhere
+      - Let’s say we were ready after the holidays, could we move then?
+      - Rob: I was more hesitant when we were more actively iterating in the
+        past year
+      - It’s still being behind the experimental function - giving ourselves the
+        opportunity to change things if needed
+      - Jeff: asked about the ability to keep w/ a previous incremental
+        transport protocol with adopting v17
+      - Lenz: multiple flags might add bundle size, etc
+      - Rob: might be hard to incentivize adopting if folks feel like they have
+        something working already
+      - Benjie: we can continue this discussion for sure - backports to v16 will
+        be there for a while, nothing urgent
+      - From chat via Yaacov: 4. is there a way to preserve both the old format
+        and the current format of defer/stream? yes, technically, for sure 5.
+        https://github.com/ardatan/graphql-tools/pull/6243 this PR allows
+        toggles for the old spec format and the new format 6. (it's a PR to a
+        fork of the executor maintained by the guild) 7. see this comment: 8.
+        `ts 9. const result = await execute({ 10. ..., 11. incrementalPreset: 'v17.0.0-alpha.2', 12. }); 13. ` 14.
+        [https://github.com/ardatan/graphql-tools/pull/6243#discussion_r1704241110](https://github.com/ardatan/graphql-tools/pull/6243#discussion_r1704241110)
+      - Lenz: 15. The problem is that we either have to ship many different
+        versions of HttpLink, which is very confusing for users, or one version
+        that grows bigger and bigger that cannot treeshake. 16. I'm less
+        concerned on the server side than on the client side
+    - Should we start EOL'ing releases
+13. Implementations may not deprecate a field that the interface hasn't
+    deprecated (10m, Benjie)
+    - [RFC](https://github.com/graphql/graphql-spec/pull/1053) - promote to
+      RFC2?
+    - Lee to give inline feedback
+14. `@defer`/`@stream` updates (10m, Rob)
+    - Editorial: move "Path" to it's own
+      section[ graphql/graphql-spec#1129](https://github.com/graphql/graphql-spec/pull/1129)<span style="text-decoration:underline;">
+      </span>
+      - Helps us reference that area in defer/stream down the line
+    - Please continue
+      reviewing[ graphql/graphql-spec#1124](https://github.com/graphql/graphql-spec/pull/1124)<span style="text-decoration:underline;">
+      </span>
+    - Rob: Current stage is RFC1, a prior design was in RFC2
+    - Benjie: RFC2 is “preferred solution” and the current spec edits get us
+      closer to that
+    - Lee: generally in support of calling this RFC2 - pretty confident this is
+      the right path
+15. Merge
+    Lee's[ Editorial changes for Event Streams](https://github.com/graphql/graphql-spec/pull/1099)?
+    (10m, Benjie)
+    - Benjie: recap
+16. When `sourceStream` errors, yield a `{ errors: [...] }` response (5m,
+    Benjie)
+    - [RFC](https://github.com/graphql/graphql-spec/pull/1127) - promote to RFC
+      1?
+    - Lenz: may impact current behavior for clients initiating restarts (longer
+      conversation, refer to recording as I did not annotate the conversation)
+17. Fix CoerceArgumentValues()' hasValue (15m, Benjie)
+    - [RFC](https://github.com/graphql/graphql-spec/pull/1056) - promote to
+      RFC2? Merge as an editorial fix?
+18. Be explicit about list coercion (15m, Benjie)
+    - [RFC](https://github.com/graphql/graphql-spec/pull/1058) - promote to
+      RFC2? Merge as an editorial fix?
+    - Lee to review
+19. Interface field argument default values (@yaacovCR, 30m)
+    - Spec
+      bug?[ graphql/graphql-spec#1121](https://github.com/graphql/graphql-spec/issues/1121)
+    - (Yaacov talks through the PR)
+    - Essentially: the identified gap may lead to runtime errors in ways that
+      may betray the intent of the schema author
+    - Benjie: (talks through their comment on the PR): essentially adding a
+      default in a way that is non-breaking for clients, but with a
+      recommendation of a stricter implementation that may require client-side
+      changes RE: defaults
+    - No bar for RFC0 so we can deem it so, RFC1 would entail spec wording
+      adjustments