RFC-0001: Propose a format and process for handling RFCs

[Illizian]

No description provided.

[tom-sherman]

LGTM, just a smol suggestion:

Can we name the RFCs in accordance to their PR number? It centers the RFC identifier around the discussion and gives you an easy way to get back to the original discussion. This means authors will need to create a 000-rfc-name.md file and swapp the 000 out for the PR number before merging. (This can be done by a maintainer/admin if the author is no longer around to do it)

[Illizian]

Can we name the RFCs in accordance to their PR number?

I wondered about the best way to handle the numbering, currently, we could have conflicts on those numbers but with its presumed low usage this would be minimal. I'm not a big fan of having to update the number after pushing the PR. Perhaps we should explore using an issue first, then create a branch from that and finalise an agreement in the PR.

GIt history on the RFC file in question will provide the required audit trail.

[tom-sherman]

Fair enough, let's see how it goes.

Perhaps we should explore using an issue first, then create a branch from that and finalise an agreement in the PR.

I don't like this idea, it splits up the conversation too much and complicates the process. I think it's better to disable issues completely and direct discussion to discord.

[Illizian]

Fair enough, let's see how it goes.

Perhaps we should explore using an issue first, then create a branch from that and finalise an agreement in the PR.

I don't like this idea, it splits up the conversation too much and complicates the process. I think it's better to disable issues completely and direct discussion to discord.

Agreed.

Ok, I'll add the example file to the repo too later

[lsymds]

In lieu of commenting on Discord and being berated for it I'll bring my concerns/thoughts here.

• This is a small community, with a small leadership group and an already active Discord - what is the benefit of segregating the discussions about the community to here when the same thing could be achieved there?
• What is the approval process?
• Who approves these PRs?
• What's stopping every PR taking 30 or more days to be merged? The RFC for the proposal of RFCs is a month old now.

[Illizian]

This is a small community, with a small leadership group and an already active Discord - what is the benefit of segregating the discussions about the community to here when the same thing could be achieved there?

It's an attempt to catalogue those discussions so they can actually be actioned and collected rather than a conversation on Discord that disappears into the ether.

What is the approval process?

Currently requires 3 PR approvals, but this could be expanded as more collaboration is received (an RFC will be raised if/when).

Who approves these PRs?

Anyone who cares to - I might need to check settings on the repo but that would be the intention.

What's stopping every PR taking 30 or more days to be merged? The RFC for the proposal of RFCs is a month old now.

Not a lot. My time is limited, and I am currently the only committed member of the leadership team.

That said, most changes are possible by the larger team. [@]moderators & [@]committee roles have the permissions required to make changes to the server upon merge.

[lsymds]

It's an attempt to catalogue those discussions so they can actually be actioned and collected rather than a conversation on Discord that disappears into the ether.

Nothing stopping you doing that on Discord with threads for each suggestion.

Not a lot. My time is limited, and I am currently the only committed member of the leadership team. That said, most changes are possible by the larger team. [@]moderators & [@]committee roles have the permissions required to make changes to the server upon merge.

If changes are unlikely to be made without sign up from people to do them, is there any point in having this process? Should that come first? Is there not a programmatic way to manage Discord to lighten the burden on the 'maintainers'?

[tom-sherman]

Deciding on what changes to make (and documenting them) is orthogonal to making those changes. These are two different problems with two very different solutions.

We've talked about ways to automate server changes already (Discord as Code, there's even a terraform provider lol), I imagine this will be one of the first RFCs.

Nothing stopping you doing that on Discord with threads for each suggestion.

This reads as a little disingenuous. There are many drawbacks to using discord threads to discuss community changes. First and foremost being that the community encompasses more than Discord.

Another big one for me is that there is no big way to track the status and history of RFCs in discord, whereas GitHub has this out of the box. There is also lots of prior art around RFC processes run through discord, React and Rust are the most notable ones that come to mind.

[lsymds]

Deciding on what changes to make (and documenting them) is orthogonal to making those changes. These are two different problems with two very different solutions.

We've talked about ways to automate server changes already (Discord as Code, there's even a terraform provider lol), I imagine this will be one of the first RFCs.

They all serve the same end goal though which is the addition or modification of the community as the whole. The former is essentially pointless without the latter, in much the same way as developing a product is pointless without users using it.

Nothing stopping you doing that on Discord with threads for each suggestion.

This reads as a little disingenuous. There are many drawbacks to using discord threads to discuss community changes. First and foremost being that the community encompasses more than Discord.

Another big one for me is that there is no big way to track the status and history of RFCs in discord, whereas GitHub has this out of the box. There is also lots of prior art around RFC processes run through discord, React and Rust are the most notable ones that come to mind.

It's not disingenuous. React and Rust are many, many orders of magnitude bigger than Norfolk Developers. There's something to be said about starting out simply and small, and growing into a different platform should the need arise. As of right now, there's only been a few people suggesting a few changes; something which could easily be managed within Discord. Should thousands of suggestions start being raised then I'd agree with you!

The same argument around Discord not encompassing the community could be made that the community encompasses more than just GitHub users.

This feels like over-engineering if that were a term able to be applied to a community forum.

[tom-sherman]

Just want to clarify some intentions of the RFC process as I think the core of it is being missed right now:

This GitHub repository and process is chiefly about documenting decision making. The process as of this PR is really simple:

1. There is an idea to change the community in some way
2. We agree on that change or discard it (we reach consensus)
3. We document agreements in this repo (#1 explains how)

Step 2 is intentionally undefined. Discussions can happen in GitHub, Discord, in person, or via carrier pigeon. The important thing is that when consensus is reached this is documented.

Also, with Step 1, RFCs are about the "what" is changing and don't focus too much on the "how". Naturally this meta proposal is very much about the how which is kind of unavoidable. I do think we could probably drop the discord.yml requirement stuff tho - I think this could be leading to some wires being crossed right now.

[lsymds]

Just want to clarify some intentions of the RFC process as I think the core of it is being missed right now:

This GitHub repository and process is chiefly about documenting decision making. The process as of this PR is really simple:

1. There is an idea to change the community in some way

2. We agree on that change or discard it (we reach consensus)

3. We document agreements in this repo (#1 explains how)

Step 2 is intentionally undefined. Discussions can happen in GitHub, Discord, in person, or via carrier pigeon. The important thing is that when consensus is reached this is documented.

Also, with Step 1, RFCs are about the "what" is changing and don't focus too much on the "how". Naturally this meta proposal is very much about the how which is kind of unavoidable. I do think we could probably drop the discord.yml requirement stuff tho - I think this could be leading to some wires being crossed right now.

If it's to document what IS changing (without the discord around changing it or not) then surely it's just a changelog rather than an RFC? There is no request, it'll have already been agreed on.

RFCs to me (especially on GitHub) are where discussions around the item and the implementation are debated. If they're not, then what is the point in the pull request functionality with reviewers and approvers?

[tom-sherman]

If it's to document what IS changing (without the discord around changing it or not) then surely it's just a changelog rather than an RFC? There is no request, it'll have already been agreed on.

I imagine it will act mostly as a changelog tbh, especially for RFCs that relate to the Discord. But there are a few ways in which being on GitHub benefits the process compared to being inside Discord:

• It is way more open. GitHub is publicly viewable without an account or being logged in. It's indexed by search engines, it can be linked from around the web.
• There is built in semantics around things being "done" (merged), and it's possible to link to specific parts of the discussion if they need to be re-addressed in the future. This is because of its open nature.
• Anyone can create an RFC and view the progress of it. This is especially important for all of the folks that for eg. attend events or are otherwise affiliated with NorDev but aren't active on Discord
• RFCs can be about more than Discord. The conference, events, tech stack of the website, blob posts, important moderation decisions, CoC changes - a very long tail of things that it would be great to be open about, basically.
• Selfishly, it's way easier to keep track of many in-flight RFCs on GitHub. It's designed for this use case.

then what is the point in the pull request functionality with reviewers and approvers?

Tbh I think requiring 3 approvers is too much, but I guess it makes sense to have Alex + Shaun + one other committee member? Not sure about what the reasoning is behind that decision tbh but I think discussing it isn't really relevant to this discussion - we can bikeshed it separately.