Status of GraphQL spec change process

[jturkel]

This repository provides an awesome opportunity for broader community involvement in the evolution of GraphQL. The change process is great start to making this engagement productive but it's been in draft status since #342 merged back on August 14, 2017. Is there anything blocking this process from moving out of draft status? As someone from the extended GraphQL community that's tracking a few issues that I'd love to see land in some form or another (#300 and #488 / #395), I think there are a few small changes/clarifications to the process that could lead to more productive community engagement:

1. The process mentions "community" several times (e.g. "Find member of community to be champion for this change", "Community consent on the proposed change") but the community isn't clearly defined. Is it a member of the GraphQL Working Group? Is it anyone who has previously made changes to the GraphQL spec? Is it anyone using GraphQL?
2. Similarly the GraphQL Working Group is mentioned a few times but the membership of that group isn't well defined (although the principles for who should be included in the group are relatively clear).
3. It's hard to correlate the issues/pull requests in this repository to stages in the process. This very much ties into the desire for a "predictable timeline of when things are going to be merged" from the working group discussion of this process. Github labels or a wiki page with the status of all proposal (e.g. the tc39 proposals page) are possible easy solutions.

Hopefully with a few small tweaks to the change process there can be more effective engagement with the broader GraphQL community ensuring continued successful evolution of GraphQL.

[jturkel]

@leebyron - The updates to contributing guidelines and cleanup of Github issues/PRs look great. They address the bulk of the points raised by this issue but I think an explicit statement on who can be a champion would be helpful. Ideally it would be any member of the community willing to perform the necessary responsibilities. It would also be useful to tag Github issues/PRs with the champion (perhaps using the assignee field).

[leebyron]

I’ll see what I can do about that. Anyone can be a champion, so I’ll edit to make that clearer. I think assignee can only be a team member, but I’ll take a closer look at GH tools

…

On Tue, Oct 2, 2018 at 8:31 AM Joel Turkel ***@***.***> wrote: @leebyron <https://github.com/leebyron> - The updates to contributing guidelines and cleanup of Github issues/PRs look great. They address the bulk of the points raised by this issue but I think an explicit statement on who can be a champion would be helpful. Ideally it would be any member of the community willing to perform the necessary responsibilities. It would also be useful to tag Github issues/PRs with the champion (perhaps using the assignee field). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#511 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADD0iMoeEDVBMXyLhyUgv4TUIzaKBqJks5ug4bugaJpZM4WTwsf> .