Add AI meeting summaries

notes/2026/summary-2026-08-20.md

@@ -0,0 +1,3 @@
+Meeting has no notes.
+
+<!-- Zoom captured blank notes... If we don't keep this file here, the sync script will keep trying to re-add blank notes. -->

notes/2026/summary-2026-09-03.md

@@ -0,0 +1,57 @@
+# 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: 2026-09-03T17:28:49Z
+- Meeting end: 2026-09-03T19:08:23Z
+- Summary start: 2026-09-03T17:28:49Z
+- Summary end: 2026-09-03T19:05:50Z
+
+The GraphQL Primary Working Group held their September meeting to discuss specification updates and review ongoing proposals. The group first addressed the spec release timeline, with Benjie and Lee planning to work on cutting the September 2026 release over the next month, though they left open the possibility of delaying to November if needed. James provided an update on the one-of-inhabitability proposal, which has been merged into GraphQL JS and is now ready for RFC3 status. The working group then spent significant time discussing Mark's struct proposal, which aims to introduce polymorphic, structured types that can be used both as inputs and outputs. The discussion centered on whether to use input unions or one-of on outputs, with Michael strongly advocating against introducing a third polymorphism approach and suggesting using existing one-of functionality instead. The group debated various implementation details including type versioning, selection sets, and how structs would handle complex nested types like GeoJSON. While no final decisions were made, the working group agreed to use one-of on outputs as the simplest approach moving forward, with Mark planning to share a Cloudflare demo to illustrate the concept in practice.
+
+## Next Steps
+
+- Benjie: Work with Lee to determine the work involved in freezing and releasing the GraphQL spec, including automating the process and creating a TSC handbook for future releases (GraphQL over HTTP, Federation).
+- Benjie: Review and tag the "inhabitability" pull request as RFC3, and perform a final editorial review before merging it into the September 2026 release.
+- Rob: Set up a time for reviewing the spec for different stream later this month and invite others to join.
+- Martin: Encourage members to file grant proposals for the remaining 2026 budget to benefit the GraphQL ecosystem.
+- Mark: Continue working on the "structs" proposal, including the spec change and GraphQL JS implementation, and share the Cloudflare Pages example for feedback.
+- Benjie: Follow up with TSC members via Signal regarding the deadline at the end of next week.
+- All attendees: Consider attending the next working group meeting in two weeks to help with last-minute merges.
+
+## Summary
+
+### GraphQL Working Group Updates
+
+The GraphQL Primary Working Group meeting covered several key topics including spec releases, grants, and technical proposals. Benjie and Lee will work on cutting the GraphQL spec release in the coming weeks, aiming for a September tag, though there's discussion about potentially delaying to November if needed. The group approved RFC3 status for James's pull request regarding one-of-inhabitable types, which has been implemented in GraphQL JS. Mark presented a detailed proposal for "structs" in GraphQL, explaining how it could address issue 300 and enable more efficient handling of complex object types, though he acknowledged the explanation was complex and would provide more details in a future blog post. The meeting also included updates on grants, with 13K remaining in the 2026 budget, and Martin encouraged anyone interested in contributing to the ecosystem to submit proposals.
+
+### GraphQL Struct Types Discussion
+
+Benjie discussed the motivation behind introducing struct types in GraphQL, highlighting use cases like GeoJSON where JSON scalars are inadequate due to embedded properties. He emphasized that structs should be used as document types for third-party library integration, similar to MongoDB, rather than comparing them to document databases. Pascal agreed on the careful communication aspect but noted that many GraphQL APIs built on top of object types, suggesting caution in the comparison with document databases. Benjie clarified that structs are intended to replace scalars with properties and are similar to input objects, making them available for both input and output while maintaining type safety.
+
+### GraphQL Structs Implementation Discussion
+
+Matt raised concerns about structs in GraphQL, arguing that they should either function as selection sets or not, to maintain their value as structured scalars. He explained that allowing explicit selection sets could compromise the ability to treat server-provided data as a "black box" and could lead to breaking changes when adding fields to input types. The discussion highlighted the need for careful implementation to ensure schema compatibility and type safety, potentially requiring a protobuf-style schema evolution approach.
+
+### Struct Design and Input-Output Types
+
+The team discussed the design of structs as input-output types, with Benjie explaining that structs should only be used for output when feeding data to the server for the first time, and must be treated as atomic types when used for input. The group agreed to exclude selection sets from structs, with Mark and Michael supporting this decision as it would maintain the contract that consumed types can be passed back as input. The discussion also touched on the concept of frozen types, with Matt suggesting that structs should have a specified and immutable structure once defined, similar to scaler types.
+
+### Union Handling in Struct Proposal
+
+The team discussed the approach for handling unions in their struct proposal, with Benjie advocating for using one-of on output rather than input unions, while Mark questioned whether to use input unions or output-only unions. Benjie emphasized that the decision is critical as it affects how dunder type names are used throughout the system, particularly for querying and feeding data back to the server. The discussion highlighted potential compatibility issues with libraries that require specific key structures, though Benjie suggested this could be addressed through nested trimming of dunder type names.
+
+### GraphQL Polymorphism Implementation Discussion
+
+Mark discussed the challenges of using one output approach versus input objects with polymorphism, expressing concerns about the current GraphQL JS branch implementation. Matt proposed using frozen struct interfaces that would prevent adding new fields but allow default fields to be accessed, suggesting this might be more useful than construct unions. Benjie highlighted the original motivation for struct, emphasizing the need for polymorphic capabilities and union support, particularly for use cases like Medium's block system and GeoJSON, which Mark also referenced as key examples requiring union capabilities.
+
+### GraphQL Struct Types Discussion
+
+The team discussed the use of struct types in GraphQL, with Benjie proposing that structs should only be used for reading and updating data, not for creating new data. They agreed that separate types should be used for creation and patching, with the server populating the type name automatically. Michael expressed concern about introducing a third option for unions beyond the existing input unions, arguing it would make the GraphQL type system less cohesive. The group reached consensus on using struct types primarily for read and update operations, with separate input types for creation.
+
+### GraphQL Struct Types Implementation Discussion
+
+The team discussed the implementation of struct types in GraphQL, comparing them to input objects and scalars. They debated whether to use one-of or struct approaches for handling complex data like GeoJSON, with Mark presenting examples of server-driven UI use cases. The group ultimately leaned toward using the existing one-of approach rather than introducing new polymorphism mechanisms, though they acknowledged trade-offs either way. Benjie emphasized that struct would provide benefits for type safety and client processing, while Michael expressed concerns about introducing a third way of polymorphism that could confuse developers. The discussion concluded with agreement to move forward with the one-of approach and Mark offering to share a Cloudflare example for further exploration.