FYI: introduced RFCX - Superseded label

[benjie]

Hi folks, I'm trying to tidy up the RFC tracker to make it more useful with the ultimate goal once it's good to move it under rfcs.graphql.org or similar. There's still a long way to go before then!

We have quite a lot of PRs that are closed with a status that isn't RFCX, generally because the idea itself wasn't rejected but the implementation has been replaced (typically re-written, or a new champion took over, or the old one just got too stale and it was easier to start fresh). Marking these as RFCX-Rejected felt wrong - the idea was not rejected - so I've introduced another label: RFCX-Superseded to indicate that although it's closed, it was closed because it was replaced rather than because we rejected the idea.

I don't think we need to introduce a new RFC "stage" for this, RFCX is fine, but it's useful for tracking.

This post is just an FYI, I'll close it at some point.

[martinbonnin]

I love this!

On a related topic, how doable would be to track RFCs in GitHub issues instead of (sometimes) PRs?

In my perfect world, every RFC would have a top-level tracking issue in graphql-spec that is assigned to the champion and can link to multiple PRs, discussions, issues, in graphql-wg, graphql-spec, graphql-js, etc... This gives a single bookmarkable entry point to track each RFC (Also allows filtering all the RFCs directly from the issues)

[benjie]

You're taking me way off topic, Martin, but I've been thinking about this for a while, and we have:

• RFC documents (now at https://github.com/graphql/graphql-wg/tree/main/rfcs but previously in other places too, plus different specs may have their own RFC documents)
• RFC issues and discussions (in assorted repositories across the GraphQL org)
• Pull requests (spec edits)

On top of that, we have "meta" RFCs, for example "InputUnions" or "SemanticNullability" that are not themselves a solution, but are a problem statement and a link to many different solutions which are competing.

Even within that, we often have multiple implementations, for example the chosen solution to InputUnions was "oneOf", but "oneOf" actually went through 3 major iterations (oneField, tagged type, oneOf).

RFC1+ requires "incomplete spec edits", so I think that non-PR RFCs can top out at RFC0, once the PR is opened it should replace the issue (the issue essentially becomes a "meta RFC", so it can link to multiple actual solution RFCs). The main things we care about should have open spec PRs, and so we should be able to manage them from there.

Further, an issue can only be edited by the creator and TSC members, so when a champion changes it's a pain - we can either close the issue and open a new one, or we have to relay all edits they want to make through a TSC member which is not efficient.

---

What I've realised with all of this is that what we actually have is a graph (!!) of RFCs. RFCs that contain RFCs that sometimes contain other RFCs! We have problem statements, we have proposed solutions, etc.

I don't want to burden us with bureaucracy, so as much as possible I want to make the current process work and be augmented as little as possible. I have a new proposal for how we handle RFCs brewing, but before we can get to that I need to tidy up what we already have to make sure my proposed solution covers all the edge cases.

[benjie]

Back on topic: I've also figured that RFCX can "override" other RFC labels, so I'm allowing items that go RFCX to retain their "highest level achieved" RFC status. So you can be RFCX/RFC2 meaning the proposal reached RFC2 before it was ultimately rejected.

[martinbonnin]

Further, an issue can only be edited by the creator and TSC members, so when a champion changes it's a pain - we can either close the issue and open a new one, or we have to relay all edits they want to make through a TSC member which is not efficient.

Yikes, that's a pain. To make another completely off-track suggestion, I wouldn't be opposed to giving more write access to graphql-wg and consolidate the list of RFCs there. Lower the barrier to contributing to graphql-wg.

What I've realised with all of this is that what we actually have is a graph (!!) of RFCs

Looking forward to the GraphQL RFC voyager 🤓 🚀 !!

[benjie]

Yikes, that's a pain. To make another completely off-track suggestion, I wouldn't be opposed to giving more write access to graphql-wg and consolidate the list of RFCs there. Lower the barrier to contributing to graphql-wg.

So again you're pushing me to say things a little early, but my current thoughts is that when an RFC spreads across multiple things (e.g. multiple PRs) then we should encapsulate it into a named container RFC which could be represented via a document in the RFCs folder, much like the InputUnions/SemanticNullability RFC documents. PRs should then link back to this (Solution to: https://github.com/graphql/.../rfcs/NameOfRFC.md) and the document should also link back. Since anyone can send PRs to those files and RFC PRs are accepted easily, we could even use the automerge functionality we use for agendas to auto-approve edits to them without needing to grant individual users permissions.

[martinbonnin]

Nice!