Creating a community fork.

[bbuck]

I'm pretty sure this isn't the most appropriate way to do this, but I wanted to put it somewhere users may happen across.

I've used this library pretty much exclusively for my GraphQL needs in Go, but lately I've been pretty disappointed in how up to date this project has become. I've seen a lot of contributions sit idly by, issues go seemingly ignored, etc...

I've been wanting to fork it for a while now and get some of the PRs merged in and some updates applied to it but I wasn't sure if the community would be behind that or not. So my proposal is (and it doesn't have to be that does it) that we create a community version of this with a bit more contributors tied to it and ideally keep this thing trucking along into the future.

Thoughts, concerns, anyone on board?

[sogko]

Hi @bbuck, @chris-ramon

Thank you for bringing this up, this has been long overdue and I appreciate the time both of you have given all this while. I do hope that you continue be part of this as well.

I'm sorry that I have not been actively working for some time. Unfortunately, I have been tied up with other projects at the moment, and I can only commit to work on improving this library on my free time, which at the moment is pretty scarce, I'm afraid :(

I would still would like to this library to continue to grow, and would very much like to continue to contribute. Two of the projects that I'm working on use this library, together with one of my personal project has been in production since Feb 2016. I definitely see myself advocating the use of this library for my future projects as well.

I've pulled @chris-ramon together in the beginning to move the library his project into a graphql-go organization, hoping we can attract more people from the community to help with continual development of the library he initially started. I still do believe we can do that.

graphql-go is not part of any commercial entity nor it is sponsored by any organization. Thus, every one that has put time into this has solely done so in the spirit of open-source. This organization was intended to be community-driven and I believe it will continue to do so.

I think right now I believe the reason to the seeming inactivity here is two-fold:

• that we don't have enough people to commit to this project. (Personally, I can't guarantee that I can give as much attention to graphql-go as much as I would really love to, that is until mid-March, when I'll have more availability.)
• we need to build a better team,
  • getting more people as org members with repo access
  • figure out how to express availability
  • delegating roles

At this moment, on my end, I can work on the following:

• Merge v0.6.0 PR that has been sitting for awhile. (like so overdue)
• Triage some of the PRs and issues (I would need help with this, if anyone would like to help out, that would be great.)

To start off, can I propose three things:

• @bbuck Can I kindly ask that you re-consider forking the library, and consider taking a bigger active role in graphql-go?
• Identify existing active contributors and bring them in as members (@bbuck, you're already an obvious choice. Would you accept an invite?).
• We need to build a better team to maintain graphql-go org and community. We definitely need time to work on that. For those interested in being more active and taking more responsibility into graphql-go, do express your interest here. From there, we can figure out a way to bring everyone together.

I really hope that we can grow this and bring in more people into this.

Would love to hear your thoughts.

Cheers!

[bbuck]

@sogko

This is basically why I created this as an issue. More of a discussion point. I'd hate to see work get fractured and splitting the community. I've advocated GraphQL and this library many times. My current place of employment uses this library as well (well they did fork it, but because they wanted support for non-GraphQL standard features). So I'd love to see it continue to advance and grow here, where it sits.

I think it's a great idea to grow the collaborator base. I'd be honored to step up and what I can help to see this library become the go to source for GraphQL support in Go.

Like I said, this was more of a discussion point, I didn't want to do anything like splitting the community until I got some feedback from actual users of the library and it was only as a last ditch effort. I'd definitely hate to take the project away from @chris-ramon and you (@sogko) since you've put so much effort into it.

[sogko]

Hi @bbuck

I totally see where you're coming from and I truly appreciate the fact that you brought this up. I think we're both on the same page as far as seeing this continue and I am glad for that fact.

To move forward, I would like us to continue having this discussion and figure out how we can keep graphql-go moving together. I've sent you a message through gitter, could we follow up through that? (Let me know if you prefer other channels)

I would still like to see feedback and thoughts from others; so if anyone interested in taking an active role in graphql-go, feel free to express your interest here. 👍

Thanks again!

[christianpv]

Hi @sogko,

I have been following this project very closely since it was release. I haven't commented or contribute anything yet but I would like to contribute in the future as I'm building an app that will need to use GraphQL.

At the moment I'm learning GraphQL, and was thinking about building my own library since this was unmaintained. If it truly becomes a community project, I would like to participate.

I think for keeping the discussion going we need to keep this issue open, or we need to add a link on README.md.

Thanks!

[sogko]

@christianpv Excellent! I'll invite you into the discussion, we'd have to figure out a way to get people together. I've pm-ed you on Gitter 👍

[SCKelemen]

@sogko, can you add me to this as well. I've been using this library for a few projects, but I've had to fork it in december, in order to merge. I'd love to see an active GraphQL Lib in Golang, as all 4 I found, are essentially dead at this point.

[chris-ramon]

Thanks a lot for bringing this up people, and specially to @bbuck and @sogko; great points there; let's take an action on this, and to summarize I'd like to propose the following:

• Add contributors to the project with write access.
• Have a strategy via tags on issues and pull request to prioritize them.
• Have an open sync, via google hangout to coordinate tasks and roles.
• Have a wiki page, to list organizations/projects using this lib, so we maybe can reach them out to ask for further improvements on the lib, and their use cases that we might want to focus on.

[SCKelemen]

I think that updating to the latest spec should be prioritized pretty high, as well as more in depth documentation.

[chris-ramon]

I think that updating to the latest spec should be prioritized pretty high, as well as more in depth documentation.

good call! @SCKelemen , totally agree, therefore:

• Add contributors to the project with write access.
• Have a strategy via tags on issues and pull request to prioritize them.
• Have a milestones for catch-up on latest graphql spec.
• Have an open sync, via google hangout to coordinate tasks and roles.
• Have a wiki page, to list organizations/projects using this lib, so we maybe can reach them out to ask for further improvements on the lib, and their use cases that we might want to focus on.