Add AI meeting summaries

notes/2025/summary-2025-05-01.md

@@ -0,0 +1,73 @@
+# Meeting Summary for Working Group Meeting
+
+**NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated
+content may be inaccurate or misleading. Always check for accuracy. If in
+doubt, please consult the meeting recording at
+https://youtube.com/@GraphQLFoundation/playlists
+
+- Meeting start: 2025-05-01T17:27:27Z
+- Meeting end: 2025-05-01T19:01:33Z
+- Summary start: 2025-05-01T17:30:29Z
+- Summary end: 2025-05-01T19:01:19Z
+
+The GraphQL specification Working group discussed the deprecation of old versions of GraphQL JS, the proposal for defining a GraphQL request's response, and the clarification of the types of GraphQL responses. They also discussed the implementation of one-off features in GraphQL, Java, and GraphQL.js, the prevention of skip and include on route subscription selection sets, and the default value coercion rules. The group also discussed the need for a source of truth for built-in scalars and introspection types, the syntax for defining schemas in GraphQL, and the issue of error propagation in GraphQL.
+
+## Next Steps
+
+- Benjie to deprecate all versions of GraphQL.js prior to Version 15.
+- Lee to review and merge the PR for "implementations may not deprecate a field that the interface hasn't deprecated".
+- Lee to review and provide feedback on the "data collections trilogy" PRs.
+- Lee to review and merge the "one of" PR.
+- Benjie to bring back the discussion on enabling a naked version of the schema keyword to a future working group meeting.
+- Benjie to continue exploring options for disabling error propagation via a request parameter and seek input from the group.
+- Lee to explore making error propagation behavior a property of the service rather than the schema.
+- Yulie to review the proposed renaming of "execute grouped selection set" to "execute collected fields".
+- Working group members to provide feedback on the "define execution as in before execution begins" PR.
+- Lee to review and attempt to merge as many of the discussed PRs as possible.
+- Working group to reintroduce mid-month meetings until July or the spec release.
+
+## Summary
+
+### GraphQL Specification Working Group Introduction
+
+In the meeting, Benjie welcomed everyone and introduced the GraphQL specification Working group. He reminded everyone of the agreed-upon guidelines and the recording of the meeting. Lee then took over and introduced the attendees. The conversation ended with a round of introductions from the participants.
+
+### GraphQL Request Response Proposal
+
+In the meeting, Benjie discussed the deprecation of old versions of GraphQL JS, with a new version policy to be implemented. Lee thanked Benjie for his work and encouraged Rob to proceed with his next item. Rob presented a proposal for defining a GraphQL request's response, which was well-received by the team. NYC clarified the changes, particularly the separation of errors that occur before and during execution. The team approved the proposal, with Lee expressing his satisfaction with the clarity of the changes.
+
+### GraphQL Response Types Clarified
+
+The group discusses a pull request that clarifies the types of GraphQL responses. They consider whether different media types are needed for various response types, concluding that the existing GraphQL response and JSON format should suffice. The conversation touches on how subscriptions and deferred responses might be handled, though these are not addressed in the current pull request. Lee expresses enthusiasm for the direction of the changes, appreciating the clearer definition of response types. The group then moves on to discuss and merge a proposal about interface field deprecation.
+
+### Data Collections Trilogy Discussion
+
+In the meeting, Benjie discussed the data collections trilogy, which includes three pull requests. The first defines the data collections used in the spec, the second recommends maintaining the order of things, and the third specifies the specific ordering of certain things. Lee and Michael discussed the order of enum values and the potential for breaking existing implementations if order is enforced. Pascal suggested a difference between the result and the schema, as the order of fields in the result can be controlled, but not in the schema. Lee proposed making most things ordered but not requiring it, to avoid breaking existing implementations. The team agreed to merge the first pull request and review the second and third ones. The changes are intended to be editorial, clarifying the meaning of terms like list and set.
+
+### GraphQL, Java, and GraphQL.js Updates
+
+Lee and Benjie discussed the implementation of one-off features in GraphQL, Java, and GraphQL.js, with Benjie suggesting a final check before merging. They also discussed the prevention of skip and include on route subscription selection sets, with Benjie stating that it has already been merged into GraphQL.js. Lee expressed interest in revisiting subscriptions in general to improve clarity. Benjie then brought up the default value coercion rules, which he believed had been merged into GraphQL.js and was good to go. Martin added a discussion about making include deprecated, non-nullable, which Lee agreed to merge.
+
+### GraphQL Scalar Source of Truth
+
+In the meeting, Martin discussed the need for a source of truth for built-in scalars and introspection types, which led to the creation of an appendix. Benjie reviewed the appendix and suggested that it should align with the main spec. Lee proposed that the appendix should be a single GraphQL code block, auto-generated from the latest version of GraphQL.js, and that any improvements should be made to both the appendix and the main spec. The team agreed to add the appendix to the pull request and to keep custom scalars separate.
+
+### Enabling Naked Schema Keyword Discussion
+
+Benjie proposed enabling a naked version of the schema keyword, which would allow for adding a description or directives without defining the operations. This change would be a breaking syntax change, as older versions of GraphQL wouldn't be able to parse it. The main problem this change would solve is allowing for the addition of a default error behavior to an existing schema without having to define the operation types. The team discussed the value of this change, with some members questioning the need for it. Michael suggested that the symmetry with interface and union type definitions was a good reason to make this change.
+
+### GraphQL Schema Syntax Discussion
+
+The group discusses the syntax for defining schemas in GraphQL, particularly focusing on whether empty curly braces should be allowed and if the 'query' type should be explicitly defined. Benjie proposes a more concise syntax for simple examples, while Lee expresses concern about potential ambiguity. The discussion touches on the placement of directives, whether they should be on the schema or root types. Michael mentions the need for a place to put general settings in schemas. Benjie suggests continuing the discussion in a future working group meeting.
+
+### GraphQL Error Propagation Solutions
+
+Benjie discussed the issue of error propagation in GraphQL and proposed a solution to disable it. He suggested adding a directive to operations and using a request parameter to control error behavior. He also proposed three error behaviors: propagate, no propagate, and abort. Benjie suggested using a reserved behavior directive to specify the default error behavior in the schema. However, he acknowledged that this approach could break existing tooling. He presented alternative solutions, including using a specified type or breaking the error behavior into multiple properties. Benjie sought input on the best path forward.
+
+### GraphQL Error Handling Directive
+
+The team discussed the implementation of error handling in GraphQL. They considered the use of a new directive, "error behavior," which would override the default error handling. The team also discussed the potential for this directive to be expressed only in introspection and not in the schema definition language (SDL). They debated whether every GraphQL client should be an error handling client and whether the "error behavior" directive should be included in the SDL. The team also discussed the issue of older versions of GraphQL.js not recognizing the "error behavior" directive, which could cause validation errors. The team agreed to fix this issue in future versions of the GraphQL client, Graphical.
+
+### GraphQL Error Propagation Discussion
+
+The group discusses two main topics: error propagation in GraphQL and the naming of execution-related functions in the spec. Benjie proposes moving towards a future where error propagation is disabled by default, but still supported for certain clients. Lee and Pascal express concerns about making this a permanent schema directive and changing defaults. The group also debates renaming "execute selection set" to "execute collected fields" and incorporating Martin's work on defining execution stages. They agree to reintroduce mid-month meetings to address time constraints and prepare for the upcoming spec release.