Gitaly RFC guide

Introduces a process for introducing RFCs.

Closes https://gitlab.com/gitlab-org/gitaly/-/issues/2835

5 files changed, 91 insertions, 0 deletions

diff --git a/.gitlab/merge_request_templates/RFC.md b/.gitlab/merge_request_templates/RFC.md
new file mode 100644
index 000000000..7f0281690
--- /dev/null
+++ b/.gitlab/merge_request_templates/RFC.md
@@ -0,0 +1,41 @@
+/title RFC: <REPLACE TITLE>
+/label ~"Gitaly RFC" ~backstage
+
+**Accepting comments until <YYYY-MM-DD> UTC**
+
+## Contributor checklist
+
+Check all items before moving onto the next section.
+
+### Pre-Review
+
+- [ ] Verify you have reviewed and understand the [RFC guidelines](doc/rfcs/README.md).
+- [ ] Replace all placeholders in the RFC template:
+  - [ ] Replace `<REPLACE TITLE>` with the RFC title
+  - [ ] Replace `<REPLACE ABSTRACT>` with a short summary of the RFC contents.
+- [ ] Replace all placeholders in this MR template:
+  - [ ] Replace `<REPLACE TITLE>` at the top of the MR description
+  - [ ] Replace `<YYYY-MM-DD>` with the UTC deadline for accepting comments.
+- [ ] Follow the [contributor guidelines for reviews](https://gitlab.com/gitlab-org/gitaly/-/blob/master/REVIEWING.md#tips-for-the-contributor)
+
+### Ready for review
+
+- [ ] Require a minimum of 2 maintainer approvals. Increase if warranted.
+- [ ] Once ready for review, announce the RFC to the Gitaly team (`/cc @gl-gitaly`)
+  - [ ] Announce a time window for accepting comments (at least a week).
+
+### Post-Approval
+
+Once the minimum number of maintainers have approved:
+
+- [ ] Wait until the declared time window expires before taking action to give others a chance to comment.
+- [ ] Once the time window expires, decide to either merge the RFC as is, or address new feedback.
+- [ ] If you choose to make changes, ping the existing approvers so that they may review the changes.
+- [ ] Merge when ready. If you do not have write access to the repository, ping a Gitaly maintainer `@gl-gitaly`.
+
+## Reviewer instructions
+
+1. Familiarize yourself with the [RFC Guidelines](doc/rfcs/README.md)
+1. Identify other reviewers who can offer constructive feedback. Offer them the opportunity to review.
+1. For your review, follow the [Gitaly reviewing guide](https://gitlab.com/gitlab-org/gitaly/-/blob/master/REVIEWING.md).
+1. Approve, but do not merge. Let the contributor merge when ready.
diff --git a/doc/rfcs/README.md b/doc/rfcs/README.md
new file mode 100644
index 000000000..a7d2a0aa0
--- /dev/null
+++ b/doc/rfcs/README.md
@@ -0,0 +1,42 @@
+# Gitaly RFCs
+
+This directory contains all accepted Gitaly RFCs.
+
+This document describes the rationale and process for Request For Comments (RFCs) in the Gitaly project.
+
+## What is an RFC?
+
+A Gitaly RFC is a document that communicates something related to Gitaly. Once approved, the RFC acts as a guideline for Gitaly contributors. In this way, it is like a Gitaly specific version of the [GitLab handbook](https://about.gitlab.com/handbook/).
+
+## Why RFCs?
+
+The motivation behind an RFC process is to address shortfalls in the typical GitLab workflow. GitLab embraces small iterations, boring solutions, and breadth of features. Gitaly is known to have complex and deep design goals (e.g. Praefect). These goals may traverse many merge requests, issues, epics and contributors.
+
+In order to preserve architectural integrity, we sometimes require thought frameworks to keep everything and everyone aligned while contributing. The inverse is also true. We sometimes end up with knowledge spread out across GitLab that we wish to collate and digest into a more accessible form.
+
+## When to use an RFC?
+
+- Use an RFC when the idea you are communicating is difficult to capture with traditional methods.
+- Use an RFC to vet a complex concept with your peers and reach consensus on an approach.
+- Use an RFC to retroactively capture the thinking behind design decisions.
+
+Note: this is not an exhaustive list. Be creative :)
+
+## When NOT to use an RFC?
+
+- Don't use an RFC when an different approach works better (e.g. issue or MR).
+- An RFC is a heavier process that consumes more time. Use appropriately when long term thinking and extensive peer review is desired.
+
+## Process
+
+### Creating a new RFC
+
+1. Start by duplicating the [RFC template](template.md) and replacing all required placeholders.
+1. Name the file using an abbreviated form of the RFC title.
+1. When ready for peer review, create a merge request using the `RFC` merge request template.
+1. Follow the template steps.
+
+### Updating an existing RFC
+
+When updating an RFC, use discretion when deciding between using the normal merge request process, or using the more process heavy RFC process. The RFC process should be used for more substantial revisions of an RFC.
+
diff --git a/doc/proposals/praefect-queue-storage.md b/doc/rfcs/praefect-queue-storage.md
index 992f18ca8..992f18ca8 100644
--- a/doc/proposals/praefect-queue-storage.md
+++ b/doc/rfcs/praefect-queue-storage.md
diff --git a/doc/proposals/snapshot-storage.md b/doc/rfcs/snapshot-storage.md
index a504c9877..a504c9877 100644
--- a/doc/proposals/snapshot-storage.md
+++ b/doc/rfcs/snapshot-storage.md
diff --git a/doc/rfcs/template.md b/doc/rfcs/template.md
new file mode 100644
index 000000000..e58a17fa4
--- /dev/null
+++ b/doc/rfcs/template.md
@@ -0,0 +1,8 @@
+# RFC: <REPLACE TITLE>
+
+## Abstract
+
+<REPLACE ABSTRACT>
+
+<!--- Replace this line and start writing your RFC. Good luck! -->
+