RFC

Discussion about design decisions on Project Link.

Many changes to Project Link can be handled simply, through Github issues, Pull Requests or Mailing-List conversations. However, some larger or subtler changes, which may need a lengthy and highly technical discussions, need a different format and process.

In Project Link, such discussions take the form of Requests For Comments (or RFCs) and they live on this repository.

If you wish to take part in the conversations that shape the future of Project Link, you should watch this repository.

Submitting

If you wish to submit a new RFC:

1. If there is no Issue describing what you wish to improve, file an Issue;
2. Fork this repo;
3. In your fork of the repo, put together a document describing your RFC, in pure text or Markdown format and place it in directory text/;
4. Submit a Pull Request with your document and mention the Pull Request in the Issue;
5. Start the conversation on the dev-project-link mailing-list.

Life cycle of a RFC

Once the RFC has been submitted, several things can happen.

Hopefully, people are interesteds, so:

1. They comment on the Pull Request, pointing out limitations, or requesting clarifications;
2. They submit Pull Requests on your repo to modify your RFC, which you may accept or discard;
3. They submit counter-RFCs that they feel solve the issue better – their counter-RFC may even be based on yours;
4. The discussion continues, until either one RFC emerges as the best solution, or noone does;
5. Active developers of Project Link get the final word on whether a RFC should be greenlighted;
6. Once a RFC is greenlighted, anybody can implement it.

As our experience grows, this process is bound to refine itself.