The file was moved when we started publishing the documents with GitLab
Pages[1][2] to https://terms.archlinux.org.

[1] archlinux/service-agreements!16
[2] archlinux/infrastructure@d7d4ecbc

rfcs/0006-code-of-conduct.rst:
Add an RFC for the adoption of a distribution wide Code of Conduct, that
is currently present in the Arch Linux Service Agreements.

Signed-off-by: Allan McRae <allan@archlinux.org>

Both flags should be safe for use, on top fairly widely used nowadays
as they are enabled on latest Fedora and Ubuntu 19.10.

Signed-off-by: Allan McRae <allan@archlinux.org>

Makefile:
Add Makefile, introducing a simple `make lint` target which runs
rstcheck against all .rst files.

.gitlab-ci.yml:
Add GitLab CI integration, with a simple lint target, that calls `make
lint` in an environment with the required dependencies.

.gitlab/issue_templates/idea.md:
The template is used to lay out an idea, get feedback and find potential
contributors.

rfcs/0000-using-rfcs.rst:
Add a first, fairly simple (most of the relevant **Specification**
information is found in the README of the repository) RFC about using
the RFC system to steer Arch Linux.
Add a section about existing (fairly recent) documentation in the wiki.
Add a few sentences to outline the different entities Arch Linux
consists of and what the RFC process is improving upon.
Clarify the setup of the final comment period, after which the RFC is
either accepted or rejected.
Expand upon how and why the specialized communication channels are
insufficient for solving overarching topics.
Specify that the discussion takes place in the merge request itself.
Add information on how RFC ideas may be proposed and existing ones
browsed.
Expand specification section by a paragraph on who is allowed to create
an RFC (anyone) and explain what are the limitations for outside
contributors (they can only create an RFC if at least one Developer or
Trusted User supports the topic and helps to develop it).
Elaborate on how in the current situation the decision making process or
found consensus may be oblique to newcomers (or even long term staff)
and that RFCs serve as an ongoing standardized archive of discussions
and found consensus.
Mention GitLab's approval feature as a means to approve of an RFC
alongside the possibility to leave a comment for a more nuanced motion.

rfcs/0000-template.rst:
Add a basic RFC template that provides a structure with Summary,
Motivation, Specification, Drawbacks and Unresolved Questions.

README.rst:
Add a description about what the RFC process means and how it works in
the context of using Gitlab with merge requests to assign RFC numbers
automatically.
Provide examples for announcements and describe the workflow of how to
propose, comment on and finalize an RFC.
Add a section about who can file an RFC and under what circumstances
outside contributors are able to file an RFC (only if at least one
Developer or Trusted User supports the effort).
Add a note for how to create a merge request (i.e. allowing commits from
members who can merge to the target branch).
Add note for users without access rights to the arch-dev-public mailing
list.
Add link to creation of a new ticket for the repository as a way of
proposing an idea for an RFC.
Add a note with link to the repository issues for current or previous
ideas (in ticket form).
Mention GitLab's approval feature as a means to approve of an RFC in the
Final Comment Period.
Add section about licensing the contributions under the terms of the
CC-BY-SA 4.0 license.

LICENSE:
Add CC-BY-SA 4.0 license for the contributions.

README.md:
The initial README used markdown. We use rst now.