Graphql-ruby: Consider moving to the graphql-ruby org?

Created on 17 Oct 2017  路  10Comments  路  Source: rmosolgo/graphql-ruby

Would maintainers consider moving this to a graphql-ruby org? Similar to https://github.com/slack-ruby or https://github.com/alexa-js or https://github.com/ruby-grape? I am happy to cheerlead. Owners will be all maintainers of this and other projects that would be the "founding members". It could become a home for projects such as this one and others, such as https://github.com/exAspArk/graphql-errors and https://github.com/ashkan18/graphlient.

This would make GraphQL ruby projects much more discoverable.

It seems to exist, https://github.com/graphql-ruby, but I am sure we can reclaim it from Github.

Related: https://github.com/github/graphql-client/issues/129

Most helpful comment

That's a good point too, I'll share my approaches to these issues:

  • The walk-away problem: one day, I could disappear from open source. Sad, but it happens! I have no plans of doing this, and one way I assure graphql-ruby users of support is by offering graphql-pro. It's a one-year license with support, and I take that commitment seriously, I couldn't walk away from that without serious social consequences! If buying in via graphql-pro is not a good fit for you, you can also work against the walk-away problem by decentralizing knowledge of graphql-ruby, for example, by improving documentation or writing blog posts. That way, if I did walk away, more people would have the knowledge to pick up the project.
  • The hit-by-a-bus problem: worse than the above! I live in the flight path of our local airport, anything could happen. For that case, there are two additional collaborators on this repo, @davidcelis (GitHub) and @willianvdv (HackerOne), who could help out. Additionally, @davidcelis has write access to RubyGems for graphql.

I should mention that I'm doing my best to take cues from sidekiq on how to manage an OSS project for long-term success. Sidekiq is a _much_ more important piece of the Ruby ecosystem, but it's still in mperham's name. Personally, it makes sense: past work aside, all the _new_ grunt work still falls to me eventually, so it seems fair if I maintain ownership!

Do you think those considerations mentioned above are sufficient to cover those worst-case-scenarios?

All 10 comments

Interesting idea! If the main goal is discoverability, could we accomplish the goal by adopting the graphql-ruby topic on github, then directing people to https://github.com/topics/graphql-ruby ?

Yes, however that leaves a very important problem unsolved: when the repo is not in an organization and the maintainer (in your case you @rmosolgo) disappears there's no way to recover admin rights to a repo that are sufficient to add maintainers. You can have a very popular project and no way to move forward without a fork. Putting the repo in an org solves that problem - you and other maintainers of these repos would become org admins.

That's a good point too, I'll share my approaches to these issues:

  • The walk-away problem: one day, I could disappear from open source. Sad, but it happens! I have no plans of doing this, and one way I assure graphql-ruby users of support is by offering graphql-pro. It's a one-year license with support, and I take that commitment seriously, I couldn't walk away from that without serious social consequences! If buying in via graphql-pro is not a good fit for you, you can also work against the walk-away problem by decentralizing knowledge of graphql-ruby, for example, by improving documentation or writing blog posts. That way, if I did walk away, more people would have the knowledge to pick up the project.
  • The hit-by-a-bus problem: worse than the above! I live in the flight path of our local airport, anything could happen. For that case, there are two additional collaborators on this repo, @davidcelis (GitHub) and @willianvdv (HackerOne), who could help out. Additionally, @davidcelis has write access to RubyGems for graphql.

I should mention that I'm doing my best to take cues from sidekiq on how to manage an OSS project for long-term success. Sidekiq is a _much_ more important piece of the Ruby ecosystem, but it's still in mperham's name. Personally, it makes sense: past work aside, all the _new_ grunt work still falls to me eventually, so it seems fair if I maintain ownership!

Do you think those considerations mentioned above are sufficient to cover those worst-case-scenarios?

Thanks! I could be wrong, but I am pretty sure @davidcelis and @Willianvdv can't add more people with r/w access to this repo, while they have committer/collaborator rights. At least that's how my Github works. No?

@rmosolgo I think your documentation of the contingency plans above is pretty helpful and it gives me a lot of confidence in the project. Thanks for sharing that! Silly as this sounds you might want to add that kind of thing to the project home page and readme, as it will help people who are just discovering this library (like me) to feel confident that it is not too risky to adopt.

If you'd like to keep it in your own name, I think you should feel free. Sidekiq is an excellent project to draw inspiration from, and emulating it is a great approach

That said, in addition to the grouping of "officially supported" extensions and whatnot that @dblock pointed out, one small point in favor of making a graphql-ruby org is that it feels more professional and legitimate. You can (and should) still credit yourself as lead maintainer at the top of the project home page and readme, and I don't think it'll take visibility away from you or your other projects.

Either way works, though :)

Thanks again for building this!

I think @rmosolgo should take credit for the whole org! This would be the most important project in it.

As one of the contributors to the project, I鈥檒l admit that I don鈥檛 see any huge benefit to moving the graphql-ruby gem into an organization. It鈥檚 already easily discoverable via search and, as @rmosolgo explained, we鈥檙e not really in danger of him disappearing (I believe and trust him with regards to that assurance). Seeming more legitimate and professional could be a valid reason, but sidekiq is thriving and doesn鈥檛 do this. So I don鈥檛 really have a strong opinion one way or the other here 馃槄

I'm curious why nobody is actually addressing bus factor of 1? @rmosolgo Your second point is incorrect, none of these people can grow more maintainers, Github doesn't let you do that. Btw, I am only trying to help based on experiences with things like slack-ruby. I wrote slack-ruby-client and the last thing I want is to maintain it till I'm 80 :) Finally, @rmosolgo feel free to just close this!

nobody is actually addressing bus factor of 1

Personally, the odds of me dying are small enough that the current contingency plan (forking) is good enough for me. FWIW, I haven't written a will yet, either 馃槅

Thanks for starting the discussion on this, I prefer to keep it as-is for the time being!

Thanks everyone and thanks for your amazing work @rmosolgo!

Was this page helpful?
0 / 5 - 0 ratings