Lead Maintainer needed!!!

[acao]

We badly need someone to lead the effort to carry this project along. The monaco-graphql mode needs more work, and to be prepared for graphiql 2.0. the rewrite from 2020 has barely been touched because of other important issues. The language server is full of bugs and needs it’s own team to support it.

I need to step away from all of this work for mental health reasons for a long time

[Nishchit14]

Thank you for all your efforts so far @acao

[dotansimha]

Hi @acao ! Thank you for all the work you are doing! Me and The Guild would love to collaborate and join as lead maintainers :)

[timsuchanek]

Thanks for raising this @acao! GraphCDN would also love to collaborate and provide a lead maintainer!

[Urigo]

@acao it looks like there is a lot of individual people and organisations that are happy to help so let's focus on getting all that positive energy and using it in the best way for everyone!

What would be the process of choosing the next lead maintainer? Also what are the actual roles and permissions of that lead maintainer? How can we create a structure that uses everyone's will to help in the best way? Maybe once we'll land on a good process we could then duplicate this process also in other foundation projects where we are lacking good community support

Maybe let's start with a meeting of everyone in this thread, sharing their ideas and working together to find the right framework of work?

[joeynimu]

@acao Thank you for all the work you have put in; much appreciated.

Based on the comments on this thread, there seems to be a lot of interest which is good. I am looking forward to helping, and I echo what @Urigo said, there's a need for a framework that will act as a guide moving forward. Everyone is more than welcome :)

[acao]

I have a lot of personal, family and professional matters to attend to, so it will be some time, a few weeks at least, before I can provide a full response or help develop a plan moving forward. I think in about two weeks, I can do a remote Q&A session to help folks get started on developing a community driven plan. I can provide links and write access to our google doc draft roadmaps from last year, which are also linked from pinned issues.

answers:

• I'm not even sure if having a single person as a lead maintainer of all these projects was a good idea in the first place. It was a title given to me by graphql foundation in the absence of any other ongoing maintenance. Some folks who showed community initiative were added as maintainers and have been able to help out here and there, but we need more folks who can be committed to regular issue triage and PR review. Managing all of these products involves managing dozens of service interfaces at once, which is a lot of overhead.
• Thus, similar to my proposal from last summer, that there should be teams of maintainers and regular contributors for:
  • graphiql
  • web editor modes (monaco-graphql and codemirror-graphql). @imolorhe is already a maintainer, and @yoshiakis and others very committed to servicing codemirror-graphql even though graphiql@2 will not use codemirror. altair, insomnia, playground, many editors use this mode in this monorepo.
  • the language service itself (used by both web modes and IDEs such as vscode, sublime. vim lsp, etc)
  • the graphql-language-service-server (used by vscode, sublime, vim lsp, webstorm, etc)
  • graphql-playground (there is an issue in playground from last year, calling for a team to maintain the project through the merger with graphiql@2 SDK effort)
  • vscode-graphql (which we had planned to pull into and publish from this repo)

That said, I think for now, just two teams could emerge - one for web/monaco efforts, another for language server, and both can contribute to the shared, runtime agnostic language service layer (interface, parser, utils), but should require PR review for the other side to ensure that changes for web don't break vscode extensions, etc. Each of these should have at least two dedicated co-maintainers, who are able to help out with PR review, planning, and issue triage, on a weekly basis, and triage-level maintainers to help with triaging/squashing bugs, offering support, and documenting the hundreds of feature requests into a roadmap

Some other important things to note (sorry this is a braindump for now):

• there has always been positive energy and excitement around new maintainers! I'm just hoping by formalizing the call that it creates an imperative. Most who have offered to maintain are only able to donate bits of time, and then as it turns out are unable.
• Advancing the OSS monaco-graphql is probably the most important component of advancing GraphiQL and the @graphiql/react sdk
• we have added ~5 new maintainers in the past year, so this is really not an "opening up". the call for maintainers has been open for a while, as per previous tweets and pleas on discord, and was usually offered to people who opened PRs and have helped triage issues. by creating a ticket i have formalized it, but I have been trying to make this happen for almost a year now since I burned out severely last summer.
• the graphiql 2.x rewrite is missing bug fixes and features from 1.x (part of the issue of rewrites), and basically needs to be rewritten around a new state management and architecture proposed in the discussion about graphiql 2.x alternative architecture. of course, it's up to the community to decide on an architecture, but I will promote the @graphiql/react and @graphiql/toolkit SDK approach over plugins, because many of the more advanced customization needs would be better served by an SDK architecture after several years of deliberation.
• all releases to graphiql package must be patch releases for now until a major internal initiative is completed
• deploy previews are broken, and the CLA bot still blocks PRs generated by bots, event though humans are required to merge them. this is a graphql foundation issue we need to address
• the LSP server is filled with bugs and needs a lot of TLC, test coverage, and a cypress suite testing the vscode-graphql reference implementation. graphql-config needs upgraded. a set of graphql config loader extensions will serve to re-architect the parsing intelligently, and prevent the LSP from needing to duplicate work in order to return positional information from template tag parsing, and to support multi-language parsing.
• issue menu and issue forms both became available while maintaining this project, and I never finished any PRs to add them. this would go a long way in cutting back on triage work, and making it easier to report specifics for language server issues vs graphiql issues, vs lower level service layer bugs such as codemirror-graphql or monaco-graphql. the many service layers are a powerful feature of this monorepo but from documentation, to triage to planning, factoring in these different service layers as distinct products with distinct needs will help tremendously
• 50% of triage & support are people seeing the graphiql logo and reporting issues with whatever graphql implementation they are using, from any of dozens of language communities. there has to be a way to cut back on this with better documentation and user waypoints, but either way, handle these noveau users gently, as we were all brand new to graphql at some point <3
• there is already an effort by users in discord to revive the working groups. please start holding these every month or even more often and I will hopefully be able to attend them soon!

[acao]

Also I want to add that I really really appreciate all the support, guidance and compassion the community has shown me over the years. If I had handled my role as "lead maintainer" better, the repository would be more autonomous and co-led by dedicated maintainers already, and probably much further along than it is. Also big props to @benjie, @leebyron , @brianwarner and @IvanGoncharov for mentoring me and believing in me, and helping me to get this as far as we have been able. And a round of applause each for the many contributors and co-maintainers who have helped me along the way, too many to name!

I hope over time I can transfer knowledge and whatever useful vision, and I know that it will be better off in the long run. I would love to come back just as a contributor, and be able to pick feature requests and bugfixes off one of the roadmaps (wouldn't we all? 😆 ).

As questions come up, feel free to tag me, and I will do my best to help in the many places where code comments, documentation or planning are incomplete or missing.

[acao]

more maintainers & advice for training maintainers: https://github.com/graphql/graphiql/pull/1957

[jasonkuhrt]

Just wanted to chime in here and say best of luck @acao and thanks for the work put in to date. It is a huge surface area and mountain of knowledge. From reading this thread and seeing familiar faces like @timsuchanek @Urigo I feel the future can still be bright, nay shining :) 🙌

[acao]

thank you @jasonkuhrt ! It was an honor inheriting playground, and an honor passing on the torch to such brilliant and dutiful maintainers!

[aexol]

We can help. Either as @graphql-editor @aexol-studio. I don't think we will be good maintainers, but we can help with features. I would recommend @Urigo and company for maintaining all the stuff

[acao]

rad! urigo and dotan are co-maintainers as of a month ago, I'm happy to say. both new contributors and co-maintainers are more than welcome! hoping to spend some time making this repository easier to contribute to

[acao]

I have opened a separate issue for those interested in helping with the graphql-language-service-server and vscode-graphql. really excited for all the folks who have shown interest in helping with these projects over the years, we have some exciting work ahead of us!

there are many many fantastic contributors to graphiql, playground and vscode-graphql repositories, so it's really a winning situation. we're finding ways to improve the contributor experience over the long run to make everyone's lives easier as well.

[acao]

GraphiQL WG tomorrow! Please join us if you'd like to help with the GraphiQL 2.x or LSP efforts, and to meet the new maintainers who are taking over for me!

https://t.co/OFUOCT2Q7c

Here is the roadmap I made last year, plenty of items to work on with detailed write-ups and everything!

https://github.com/orgs/graphql/projects/1/views/7

[acao]

last year i created, pinned and promoted a roadmap for graphiql 2 which is entirely react and product design at this point

https://github.com/orgs/graphql/projects/1/views/7

let me know if you’d like to help! More items can be added.

I also last year created a pretty exhaustive LSP/vscode-graphql roadmap that we still need to convert to the new github projecta beta:

https://github.com/graphql/graphiql/issues/2122

All of these roadmap items are fair game, feel free to ping me on discord if you have questions and I’ll try to get back to you within 1-3 days.

We also need someone to host the working groups. @patrick91 from strawberry graphql has offered, and @timsuchanek is looking into potentially helping with this as well.

He is also working with GraphCDN’s product designer Julian to produce more design iterations for the final graphiql 2!

There are lots of housekeeping issues as well, so I can create a separate github project for that. Documentation, fixes to deploy previews, documentation site, merging vscode-graphql and it’s pipeline, etc

[patrick91]

@acao happy to help hosting the WG meeting again, I didn't have time in the last couple of months as I was changing jobs :)

[acao]

Yay great! I was afraid of being a bother. I’m thrilled to have you involved!

[acao]

@Urigo sorry I overlooked this important comment, I had trouble reading this wonderful thread at the time because of obvious reasons. Also sorry if the responses are staggered, I'm still in a fog

What would be the process of choosing the next lead maintainer?

The decision is really up to the graphql foundation at the end of the day. The process of assigning new active maintainers is usually to create a PR where we add them to the 'Active Maintainers' section in the Readme. I would love for the community to nominate maintainers.

If I was paying close enough attention to all the fantastic contributors in this repo, I would know who to name, but it's hard to remember who is available and who isn't. I could make a list of potential maintainers regardless of my knowledge of their current availability, but probably some of the best potential maintainers are people I've never heard of or followed on twitter :). I trust the community to decide on it's own maintainers, probably better than even my own judgement!

Also what are the actual roles and permissions of that lead maintainer?

Perhaps I should have asked for maintainer(s)? We really need several, as there are many types of users, service interfaces, tons of documentation and multifaceted support efforts. At least one for the web, and another for the LSP server, and ideally a third for playground specifically

With a strong set of co-maintainers and the many contributors we're lucky to have, some regular even, a lead maintainer may not be necessary. Again, not something I need to have the final say on.

lead maintainer description

If we could have only one paid role on this project, I would reccomend it be a lead maintainer. A lead maintainer would be responsible for either web IDE track or LSP server/vscode-graphql track, mentoring two co-maintainers for the other track and playground, improving the process for contributors and onboarding them.

The lead maintainer would also keep track of the general repo roadmap as well as the web or LSP roadmap. They would be mentored well enough to triage any tickets, resolve tickets within their track at least and review PRs within their track and the general repository.

A lead maintainer who feels fluent in both and down to the interface and parser would be amazing, and as I discuss below I'm happy to pass that knowledge on

co-maintainer description

A co-maintainer would be focused on a specific track and not "universal", repo wide efforts as much- reference GraphiQL/monaco/codemirror OR LSP server, vscode-graphql and ideally interface and parser as well. They would only need to answer tickets and PRs in their vertical, but it would be rad if they could help the lead maintainer out with peer review of their PRs.

I would love for the LSP/server track to have a proclivity towards rust (the LSP server needs optimization the most, and monaco/codemirror would benefit). But plenty of optimization and improvements could come with some good ol' node.js refactoring and improved stability & visibility.

maintainer mentorship

I will happily mentor any of these people, 1:1 or in a group format. I taught myself even the most confusing parts of the codebase over the course of several years (@IvanGoncharov and @benjie and @orta and @leeb and @frieksnet and @brianwarner were there to mentor me as a maintainer in general!), so with my brilliant peers in the graphql community, being able to directly mentor anyone for a few months will have people making moves on this repo in ways most never imagined possible

How can we create a structure that uses everyone's will to help in the best way?

That is a great question and something i've been pondering a while, and I'm open to give feedback on any ideas. I think a structure that prioritizes making sense of the terribly messy issues, documentation & general support situation, and that prioritizes ease of contributorship and "pathways" to keep, say, intrepid but front-end-focused react devs from being distracted by internals they don't need to worry about. I think it will take consulting with and learning from people who have maintained high traffic, complicated and multi-facted interdependent monorepos on this scale.

Maybe once we'll land on a good process we could then duplicate this process also in other foundation projects where we are lacking good community support

Yess!! express-graphql needs love, and I want playground-graphql's users to decide for themselves where that goes, I've pinned a few issues to the effect of the latter, need to update the readme as well

[acao]

Discussions about the maintainer structure and decision making process are happening here, for those interested!

https://github.com/graphql/graphiql/discussions/2231