RFC: RFCs and the contribution process

[LunarLambda]

(insert inception noise here)

Questions

• Should the RFC process itself be documented? I think most importantly an issue template would be good so all the important information gets included from the get-go (checklist of questions, related/blocking RFCs, time estimate for resolution, so on), but also how and when we decide to resolve

• What should the editing, review and contribution process look like? I think Pull Requests are the way to go, since it lets us make use of GitHub's review features, and hopefully prevents merge disasters.

  • Should PRs always be done against a new branch, and disallow committing to the main branch directly?

[Lokathor]

I seriously doubt we'll have so much activity that we need to complicate this. Perhaps a little more near the startup, but after that it'll be small and infrequent changes.

just PR and merge to main branch, and then have commits to main trigger a github actions to update the github pages.

[avivace]

+1 for documenting the contribution process (commit messages, branches, permissions, reviews, ...), not so sure about the RFCc process. It may be overkill for now