Document the community RFC process

llvm/docs/CodeReview.rst

@@ -93,7 +93,8 @@ intrinsics), adding language extensions in Clang, and so on, require an RFC
 first. For changes that promise significant impact on users and/or downstream
 code bases, reviewers can request an RFC achieving consensus before proceeding
 with code review. That having been said, posting initial patches can help with
-discussions on an RFC.
+discussions on an RFC. See the :doc:`RFC process <RFCProcess>` documentation
+for more details.
 
 Code-Review Workflow
 ====================

llvm/docs/DeveloperPolicy.rst

@@ -791,6 +791,7 @@ will only be done through the following process:
       library features LLVM should use; avoid miscompiles in particular compiler
       versions, etc).
     - Detail downsides on important platforms (e.g. Ubuntu LTS status).
+    - See the :doc:`RFC process <RFCProcess>` documentation for more details.
 
   * Once the RFC reaches consensus, update the CMake toolchain version checks as
     well as the :doc:`getting started<GettingStarted>` guide.  This provides a
@@ -979,7 +980,8 @@ Those wishing to add a new target to LLVM must follow the procedure below:
    your target and how it follows all the requirements and what work has been
    done and will need to be done to accommodate the official target requirements.
    Make sure to expose any and all controversial issues, changes needed in the
-   base code, table gen, etc.
+   base code, table gen, etc. See the :doc:`RFC process <RFCProcess>`
+   documentation for more details.
 3. Once the response is positive, the LLVM community can start reviewing the
    actual patches (but they can be prepared before, to support the RFC). Create
    a sequence of N patches, numbered '1/N' to 'N/N' (make sure N is an actual
@@ -1030,7 +1032,8 @@ components to a high bar similar to "official targets", they:
    clear path to resolving them.
  * Must be proposed through the LLVM RFC process, and have its addition approved
    by the LLVM community - this ultimately mediates the resolution of the
-   "should" concerns above.
+   "should" concerns above. See the :doc:`RFC process <RFCProcess>`
+   documentation for more details.
 
 If you have a project that you think would make sense to add to the LLVM
 monorepo, please start an RFC topic on the `LLVM Discourse forums`_ to kick off
@@ -1074,7 +1077,8 @@ criteria:
    suggested wording below).
  * Must be proposed through the LLVM RFC process, and have its addition
    approved by the LLVM community - this ultimately mediates the resolution of
-   the "should" concerns above.
+   the "should" concerns above. See the :doc:`RFC process <RFCProcess>`
+   documentation for more details.
 
 That said, the project need not have any code to get started, and need not have
 an established community at all!  Furthermore, incubating projects may pass

llvm/docs/Lexicon.rst

@@ -261,7 +261,8 @@ R
 
 **RFC**
   Request for Comment. An email sent to a project mailing list in order to
-  solicit feedback on a proposed change.
+  solicit feedback on a proposed change. See also: the :doc:`RFC process <RFCProcess>`
+  documentation.
 
 .. _roots:
 .. _stack roots:

llvm/docs/RFCProcess.rst

@@ -0,0 +1,80 @@
+=================================
+Request For Comment (RFC) process
+=================================
+
+.. contents::
+   :local:
+   :depth: 1
+
+Introduction
+============
+Substantive changes to LLVM projects need to be acceptable to the wider
+community, which requires gaining community consensus to adopt the changes.
+This is done by posting an RFC and obtaining feedback about the proposal.
+
+Process
+=======
+
+Writing an RFC
+--------------
+The process begins with writing a proposal for the changes you'd like to see
+made. The proposal should include:
+
+* a high-level overview of what changes are being proposed,
+* information detailing the motivation for why the changes are being proposed,
+* detailed information the proposed changes and how they impact different parts
+  of the project, and
+* a list of any open questions the community should explicitly address.
+
+Once the contents of the proposal are ready, the proposal should be posted to
+the appropriate forum on `Discourse <https://discourse.llvm.org/>`_.
+
+Feedback Period
+---------------
+Once the RFC is posted, the community will provide feedback on the proposal.
+The feedback period is a collaborative effort between the community and the
+proposal authors. Authors should take the community's feedback into
+consideration and edit the original post to incorporate relevant changes they
+agree to. Edits should be made such that it's clear what has changed. Editing
+the original post makes it easier for the community to understand the proposal
+without having to read every comment on the thread, though this can make
+reading the comment thread somewhat more difficult as comments may be referring
+to words no longer in the proposal.
+
+There is not a set time limit to the feedback period; it lasts as long as
+discussion is actively continuing on the proposal.
+
+Trivial Acceptance or Rejection
+-------------------------------
+If the proposal has obvious consensus (for or against), a maintainer for each
+of the impacted parts of the project will explicitly accept or reject the RFC
+by leaving a comment stating their decision and possibly detailing any
+provisions for their acceptance. Additionally, the original post should be
+edited to explicitly say what consensus was called and link to the comment
+stating that decision. Including that information in the post makes it more
+clear to everyone what state the proposal is in. Overall consensus is
+determined once all impacted parts of the project have accepted the proposal.
+
+Low Engagement Level
+~~~~~~~~~~~~~~~~~~~~
+If a proposal gets little or no engagement by the community, it is a sign that
+the proposal does not have consensus and is rejected. Engagement means comments
+on the proposal. If there are few or no comments but the are a lot of people
+pressing the like/heart button on the post, maintainers can make a value
+judgement on whether to accept or reject.
+
+After Acceptance
+----------------
+Once an RFC has been accepted, the authors may begin merging pull requests
+related to the proposal. The review process may identify necessary changes to
+the proposal. Minor changes to the proposal do not require an additional RFC.
+However, if the proposal changes significantly in a material way, the authors
+may be asked to run another RFC.
+
+After Rejection
+---------------
+Any rejected RFC can be brought back to the community as a new RFC in the
+future. The new RFC should either clearly identify new information that may
+change the community's perception of the proposal and/or explicitly address the
+concerns previously raised by the community. It is helpful to explicitly call
+out such information in the subsequent RFC.

llvm/docs/index.rst

@@ -86,9 +86,11 @@ LLVM welcomes contributions of all kinds. To learn more, see the following artic
    :hidden:
 
    GettingInvolved
+   RFCProcess
 
 * :doc:`GettingInvolved`
 * :ref:`development-process`
+* :doc:`RFCProcess`
 * :ref:`lists-forums`
 * :ref:`meetups-social-events`
 * :ref:`community-proposals`