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:
#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!

GraphiQL Roadmap (view)