Add AI meeting summaries (#1724)

Author: benjie

notes/2025/summary-2025-04-03.md

@@ -0,0 +1,56 @@
+# 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-04-03T17:23:52Z
+- Meeting end: 2025-04-03T19:07:03Z
+- Summary start: 2025-04-03T17:30:51Z
+- Summary end: 2025-04-03T19:07:02Z
+
+The GraphQL working group meeting focused on the importance of the membership agreement, participation and contribution guidelines, and code of conduct, with a round of introductions and an extensive agenda. The group discussed changes to the GraphQL specification regarding terminology and error handling, refactoring the execution algorithms, and the nullability working group's consensus on disabling null propagation. They also considered various approaches to handling nullability and error management in GraphQL schemas, with a preference for directive-based solutions over syntax changes.
+
+## Next Steps
+
+- All attendees to review and provide feedback on Benjie's proposal for a spec cut by July 1st through the linked issue.
+- Pascal to set up a subcommittee for the Open Telemetry specification.
+- Lee to review and potentially merge Benjie's PR on adding extensions property to requests.
+- Lee to review and provide feedback on Rob's editorial changes regarding response terminology.
+- All attendees to review and provide feedback on the nullability proposals (solutions 1, 6, and 7) presented by Alex.
+- Nullability working group to develop user stories for tooling compatibility with the asterisk syntax proposal.
+- Nullability working group to develop user stories for code-first shops regarding the nullability proposals.
+- Matt and Kewei to investigate potential issues with Martin's "include deprecated" proposal for Meta/Facebook.
+- All attendees to review the remaining pull requests linked in the agenda, particularly those ready for RFC2 approval.
+- Lee to review and potentially merge as many pull requests as possible before the next month's meeting.
+
+## Summary
+
+### GraphQL Working Group Meeting Summary
+
+Lee led the April 2025 GraphQL working group meeting, emphasizing the importance of the membership agreement, participation and contribution guidelines, and code of conduct. The meeting was recorded and summarized for note-taking purposes. Lee then conducted a round of introductions, ensuring everyone knew each other. The agenda was extensive, with 20 items, and Lee expressed concern about covering everything in the meeting. Benjie was set to present the first item on the agenda.
+
+### Spec Cut and Open Telemetry Discussion
+
+In the meeting, Benjie proposed a spec cut with a deadline of July 1st, aiming for a release by September. Lee expressed enthusiasm for this plan, aiming for a new spec cut at or before the GraphQLConf in the fall. Pascal discussed the interest in the open telemetry specification and proposed a short lift subcommittee for it. Benjie raised the issue of adding an extensions property to the request, which was approved. Martin discussed the need to explicitly forbid implementations from choking on unknown fields. Michael suggested this was more relevant to the HTTP spec. The team agreed to standardize on "result map" in the algorithm.
+
+### GraphQL Specification Terminology Changes
+
+The group discusses changes to the GraphQL specification regarding terminology and error handling. Rob proposes renaming "response" to "response payload" to clarify its meaning, especially in the context of incremental delivery. The team debates the appropriateness of the term "payload" and considers alternatives like "response map". Benjie suggests standardizing on "response name" instead of "response key" for consistency with GraphQL.js. He also proposes renaming "field error" to "execution error" to more accurately describe errors that can occur at different levels during query execution. Benjie introduces the concept of a "response position" to precisely locate where errors occur in the response structure. The team agrees these changes will improve clarity and accuracy in the specification, particularly for incremental delivery and error propagation.
+
+### Refactoring GraphQL Execution Algorithms
+
+The group discusses refactoring the execution algorithms in the GraphQL specification. Benjie proposes renaming "execute selection set" to "execute grouped fields" and introducing "execute root selection set", which aligns better with GraphQL.js implementation and simplifies various algorithms. Lee agrees this change is overdue and will review it carefully. They also discuss clarifying the definition of "execution" in the spec, with Benjie suggesting it begins when the first selection set is executed. Martin proposes renaming "execute request" to "process request" to differentiate it from execution. Lee expresses concern about internal consistency and suggests considering concepts like pre-execution to better organize the terminology.
+
+### Null Propagation Consensus and Naming Conventions
+
+The group discusses the nullability working group's consensus on disabling null propagation. They have agreed on Benjie's request parameter solution, which is considered cleaner than the previous query directive approach. This solution allows for potentially defaulting the option to true in future schema versions. The proposal aims to address issues with null propagation and support clients like Relay with normalized caches. The group plans to seek either stage 2 or stage 3 approval at the next working group meeting. Lee suggests aiming for RFC1 to confirm agreement on the problem being solved. Benjie invites feedback on naming conventions for the error handling options.
+
+### Nullability Solutions in GraphQL
+
+The Nullability working group discusses three potential solutions to address the nullability problem in GraphQL. Solution 1 introduces an asterisk syntax for semantic nullability, seen as a transitional type. Solution 6 uses a directive instead of new syntax for semantic nullability. Solution 7 proposes removing null propagation entirely and adding a "propagate error" directive to existing non-null fields. All solutions aim for the same end state, differing mainly in the transition approach. The group considers the trade-offs between introducing new syntax, backward compatibility, and ease of implementation. They also discuss the importance of making a decision, as maintaining the status quo is not without cost.
+
+### GraphQL Schema Nullability Approaches
+
+The group discusses various approaches to handling nullability and error management in GraphQL schemas. They consider solutions involving new syntax (like asterisks) and directives. The main concerns are backward compatibility, tooling support, and migration paths. Participants express preferences for directive-based solutions (6 and 7) over syntax changes. Key issues to address include figuring out user stories for tooling with the asterisk approach and for code-first shops. The group also discusses several other pull requests that need review before the next spec cut. Martin's "include deprecated" proposal is advanced to RFC2, pending confirmation that it won't cause issues for Facebook's implementation.