chore: Add RFC process

[binarylogic]

Problem

Something that has been bothering me lately is our RFC process. Up until recently (~3 months ago) changes have been mostly isolated and green-field. Discussions were less necessary and simple specifications within issues were sufficient. This was on purpose, as we should strive to reduce the process as much as possible.

Lately, though, changes have required more discussion due to:

1. Vector is becoming more mature, there are more moving parts.
2. Changes are exposing larger design questions.
3. Changes are intermingled and sometimes overlap or block each other.
4. We have subject matter experts on various parts of Vector that should be involved.
5. Scope questions are coming into play, helping to further define Vector's purpose and scope.
6. Previous RFCs are not easily discoverable.

Solution

I'd like to formalize our RFC process. I use "formalize" loosely. It is a step up from our current process but I do not intend it to be nearly as formal as real RFCs. The amount of time and effort involved in a RFC should scale with the change. You can see what I'm talking about in the new /rfcs folder:

1. RFCs will now follow a consistent pattern, which should reduce the cognitive load when reviewing RFCs.
2. RFCs are easily discoverable. New team members can obtain context on previous substantial decisions.
3. It shows that the project is professionally maintained, at least relative to your average open source project.
4. It can be improved and evolved over time, ensuring we address specific issues that have "bitten us" in previous changes.
5. Anyone in the community can weigh in on RFCs since they are more easily discoverable.

---

I'd like to get consensus from everyone on this change before it is implemented.

[MOZGIII]

If we're going to add RFCs as markdown docs, how about we also add https://github.com/DavidAnson/markdownlint? Not necessarily in this PR, but if we're going to work with markdown files even more - I think it makes a lot of sense. It supports nice things, like editor integration and autoformatting!

[bruceg]

Is isuee a typo?

[binarylogic]

Yes, it’s my damn Apple keyboard. I’ll fix it.

[MOZGIII]

So, a follow up from the sync up.

What if we put this in a separate repo? This should do a better job in isolating the RFC editing process from the code editing process. What are the benefits of having rfcs dir in the vector repo? I think there are inly the minor ones, like the usual “you have to clone just a single repo“. However, to work on an RFC one would have to always work on a dedicated branch of vector, and having a separate workspace with it’s own repo might be actually easier to switch to.

[LucioFranco]

I am 👍 on a separate repo for rfcs.

[ghost]

A few arguments for keeping RFCs inside the main Vector's repo:

• People who watch Vector's PRs using GitHub notifications feature would automatically become notified about proposed RFCs.
• It would be easier to reference issues/PRs in discussions of the RFCs, they would be rendered just as Update installation documentation #1234 rather than as fix: Fix build on macOS Catalina by explicitly invoking the shell leveldb-sys#1.
• Contributors to the Vector repository would automatically have a "Contributor" badge in the discussions of the RFCs near their name.
• Eventually we might want to link to the text of RFCs from the docs. If RFCs are in the same repo, it would be possible to just render them as special pages of the documentation website.

[MOZGIII]

• It would be easier to reference issues/PRs in discussions of the RFCs, they would be rendered just as Update installation documentation #1234 rather than as timberio/leveldb-sys#1.

Note that instead of [timberio/leveldb-sys#1](https://github.com/timberio/leveldb-sys/pull/1) toy can just use https://github.com/timberio/leveldb-sys/pull/1:

[timberio/leveldb-sys#1](https://github.com/timberio/leveldb-sys/pull/1): timberio/leveldb-sys#1
https://github.com/timberio/leveldb-sys/pull/1: vectordotdev/leveldb-sys#1

[lukesteensen]

I'd like to see an Alternatives section in the template, but otherwise this looks good to me.

[MOZGIII]

A few arguments for keeping RFCs inside the main Vector's repo:

• People who watch Vector's PRs using GitHub notifications feature would automatically become notified about proposed RFCs.
• It would be easier to reference issues/PRs in discussions of the RFCs, they would be rendered just as Update installation documentation #1234 rather than as timberio/leveldb-sys#1.
• Contributors to the Vector repository would automatically have a "Contributor" badge in the discussions of the RFCs near their name.
• Eventually we might want to link to the text of RFCs from the docs. If RFCs are in the same repo, it would be possible to just render them as special pages of the documentation website.

To me personally, I only see the last one as really beneficial. If we plan to link RFC on the website - we'll have an easier life if it's in the website repo - that currently being the vector repo. However, we might want to move it out as well (only leaving the docs in the vector repo, since they and the code have a shared lifecycle).

If we have two repos, people will be able to watch just one of them - for example, somebody might be interested only in the RFCs. So, in regards to repo watching, there are two sides to the coin.