Brainstorming possible subgroups

[doc-jones]

Continuing the brainstorming discussion from the Feb 13 community-wg meeting. Subgroups that we might initiate depending on members' desire to contribute to these areas.

• Website operations
• Content creation
• GraphQLConf
• Budget
• Community Metrics
• Survey
• External communities engagement (crypto, AI, data, other standards, other)
• GraphQL activities promotion (socials, other)
• Tools and templates

We could discuss here and with the larger community on setting priorities for subgroups. Please free feel to add your ideas and thoughts to a comment on this issue.

[martinbonnin]

Trusted documents swag and cookies!

[jemgillam]

Add "local gatherings" organisation?

[erikwrede]

+1 for local gatherings!

Here are a few other key areas I think we should focus on:

1. Discord & Online Communities - Let's consider how we can best engage and support our virtual hubs where tons of GraphQL discussions are already happening.

2. Branding -How do we present GraphQL to the outside world at conferences, on the website, etc. What should newcomers see first? Which strengths of GraphQL do we want to highlight as we move forward? Also in reference to @bignimbus + @benjie comments last meeting, how should we present GraphQL so we reach everyone we want to reach

3. Maintainer Outreach - I'm generalizing, but a large portion of WG committee members work in Enterprises or at GraphQL Vendors. There is a large group of people out there maintaining GraphQL tooling, championing GraphQL in their local communities, and working on making GraphQL more accessible to the open source community. I see high value in actively trying to form meaningful connections with the wider community - they are the ones that can spread language proposals into their respective discords & communities.

On a broader note, I suggest we spend some time collaborating on these topics as a single group before diving into subgroups. Establishing a shared mission with our diverse perspectives is essential, and it would strengthen any subgroups we form later. That said, I'm open to smaller teams focusing on specific areas if there's a strong interest, but let's make sure we're not rushing to split up our efforts into completely separate meeting series too soon.

[benjie]

I suggest we spend some time collaborating on these topics as a single group before diving into subgroups

💯

Maintainer Outreach

💯 We have @graphql/implementers team but there's not enough people on it - we really need a way of pinging implementers and telling them we're working on a major feature and we need input / validation / testing. Maybe an "implementers" mailing list or blog or similar might be a good solution to that? But also, how do we inform them if there's some kind of security issue or similar... Definitely an unsolved problem in the space.