GraphQL Working Group: the meeting notes and RFCs behind the specification

Who sits in the room and who can join

The GraphQL Working Group is a set of recurring virtual meetings of maintainers of commonly used GraphQL libraries and tools, plus significant contributors to the GraphQL community, hosted by the GraphQL TSC as part of the GraphQL Foundation.

The membership rule is the part that catches people out. Anyone in the public GraphQL community may attend a GraphQL WG meeting, provided they first sign the Specification Membership Agreement or belong to an organization which has signed. So the door is open to individuals who fill in one form, and to company employees whose employer has already signed, and it is not open to a company that has not signed and whose employee has not signed individually.

Everything happens over video conference, and the README adds that participating company offices are welcome to host guests. The guide on how to join a meeting is a separate document, JoiningAMeeting.md, and there is a GraphQL-TSC.md for the technical steering committee that hosts the group.

The last push to the main branch was on 2026-10-22, the repository is not archived, and it publishes no GitHub releases, which is normal for a repository whose content is meeting records rather than software.

The repository is agendas, notes and RFCs, and anyone can edit an agenda

The repository holds agendas and notes for all meetings past and upcoming, as well as shared rfc documents. The top level listing shows the directories that make this up: agendas/, notes/, rfcs/ and membership/, alongside the two guide documents, a wg.config.js, a package.json and a yarn.lock.

The permission model is worth understanding, because it is unusual. Anyone may edit an upcoming event's agenda, in order to attend or to propose an agenda item. There is no application to the WG, no selection process, and no permission check on the pull request. The README describes the practical flow: to request participation in an upcoming meeting, send a pull request by editing the relevant meeting agenda.

So an agenda file is a signalling mechanism rather than a document of record. Editing it says you plan to attend, or that you want a topic discussed, and the meeting itself then decides what to cover. The minutes end up in notes/, and the proposals that need more than a discussion end up as documents in rfcs/.

For a reader who never attends anything, that structure is the value. The notes directory is a searchable record of how the specification reached its current shape, including the arguments that lost, and the rfcs directory is a set of worked examples of what a GraphQL proposal document looks like.

Three meeting slots, one of them on hiatus

There are three slots in the meeting table, and the current state of each is different.

The primary meeting is on the 1st Thursday, 10:30am to 12:00noon Pacific time, hosted by Lee Byron. The secondary meeting for Europe is on the 3rd Thursday at the same time of day, also hosted by Lee Byron. The secondary meeting for Asia Pacific was on the 2nd Wednesday, 3:30pm to 5:00pm Pacific, and it is marked as on hiatus. As of November 2024 the Asia Pacific meeting is on hiatus, and the README says that if you wish to attend you should file an issue and they can restore it easily.

The primary monthly meeting is preferred for new agenda. The secondary meetings exist for overflow agenda items, follow ups from the primary meeting, or agenda introduced by people who could not make the primary time. The two secondary meetings are each timed to be acceptable for people in either an Asia Pacific or European timezone, which is the constraint that explains why there are two of them rather than one.

Two practical points follow from that design. If you only have time for one meeting, attend the primary, because that is where new agenda is preferred to be raised. And the published times are only typical, since the README says to always check the agenda for the exact date and time of an upcoming meeting. Upcoming meetings can also be tracked by subscribing to the Google Calendar or the ical feed, both linked from the README.

Eight subcommittees doing the actual design work

The Working Group proper is where the specification is agreed, but the README describes subcommittees that focus on the development of specific projects beyond the GraphQL Spec. They make progress within their own meetings and report back progress and decisions to the Working Group meetings.

There are eight active ones, and the schedule shows they are timed for different regions: GraphiQL on the 2nd Tuesday, GraphQL-over-HTTP on the last Thursday, Composite Schema every Thursday in Central European time, GraphQL.js on the last Wednesday, Community on the 2nd Thursday, GraphQL/OTel on the 4th Thursday, AI on the 4th Thursday, and Golden Path on the 2nd Thursday.

Each has its own host and, more importantly, its own agenda repository. The table links GraphiQL to graphql/graphiql/working-group, GraphQL-over-HTTP to graphql/graphql-over-http/working-group, Composite Schema to graphql/composite-schemas-wg, GraphQL.js to graphql/graphql-js-wg, Community to graphql/community-wg, GraphQL/OTel to graphql/otel-wg, AI to graphql/ai-wg and Golden Path to graphql/golden-path-wg. So the notes for those discussions are not in this repository, they are in the project repositories, and the split is a deliberate consequence of the work belonging to a project rather than to the specification.

The AI and GraphQL/OTel subcommittees are the newer entries in the table, and the topics on the list hint at where the community's attention has moved: the specification itself is stable enough that a separate Composite Schema group exists, and there are now groups for tracing and for AI.

Two subcommittees on hiatus, and a way to revive one

Not every group is running. The README has a section for subcommittees on hiatus, with the explanation that they are typically not meeting due to lack of agenda topics. The instruction for anyone with something to discuss is to raise an issue in the WG repository and mention the host.

Two are listed. Incremental Delivery meets on the 2nd Monday, 10:00am to 11:00am Eastern, hosted by Rob Richard, with its agenda repository at graphql/defer-stream-wg, and the table notes it has returned to the main spec WG for review. Nullability meets on the last Wednesday, 19:00 to 20:00 UTC, hosted by Alex Reilly, with its agenda repository at graphql/nullability-wg.

The Incremental Delivery entry is the interesting one, because defer and stream is not a small feature. It was a proposal of its own with its own working group, and it has now gone back to the main spec working group for review, which means it is close to a decision point rather than parked.

The hiatus mechanism is also a small piece of governance design. Rather than cancelling a dormant group, the group stays visible in the table with its host and its agenda repository, and a single issue is enough to bring it back. The alternative would be to delete the row and lose the routing information.

Agenda files are generated, and that is the only code here

There is exactly one piece of tooling in the repository, and it exists to remove a chore.

To create the agenda files for a given month in YYYY/MM form, you run yarn and then the gen-agenda command with the year and month:

yarn && yarn gen-agenda YYYY MM

The package.json shows the whole implementation. The gen-agenda script is wgutils agenda gen, and the only devDependencies are prettier and wgutils itself. The prettier configuration sets proseWrap to always, which is why every markdown file in the repository has its prose wrapped at a fixed width, and there is a .prettierignore alongside it.

So the workflow is: the files for next month are created mechanically, people edit the agenda file to signal attendance or propose a topic, the meeting happens, and the notes are written up. The generator removes the possibility of a month having inconsistently named agenda files, which matters in a repository where the file path is the lookup key for a meeting.

The main alternative for a developer who wants to influence GraphQL is to write an RFC against the specification repository directly, using the RFC process that the contributing guide describes. The Working Group is where those proposals are discussed and agreed, but the work of writing the proposal happens in the specification repository, and this repository is where you can read what previous proposals looked like.

Editorial conclusion

Adopt graphql-wg as a reference, not a dependency: read the notes for the meetings where a feature you use was debated, and follow the rfcs directory to see what a proposal looks like before you write one yourself. Do not expect it to be code, because it is a governance repository with a single script for generating agenda files. Before you attend a meeting, sign the Specification Membership Agreement or belong to an organisation that has signed it, and check the agendas directory for the exact date, because the README says the published times are typical rather than guaranteed.

Frequently asked questions

Official sources

1. graphql/graphql-wg on GitHub
2. Issues
3. README