Documentation on how to make a release. (#31426)

* Release Engineering Docs with pointer to the Docs on how to actually make the release.

docs/docsite/rst/community/development_process.rst

@@ -10,6 +10,12 @@ Road Maps
 
 The Ansible Core team provides a road map for each upcoming release. These road maps can be found `here <http://docs.ansible.com/ansible/devel/roadmap/>`_.
 
+.. Roadmaps are User-oriented.  We should also list the Roadmap Projects and the Blocker Bug
+   Projects here
+
+.. How the actual release schedule, slipping, etc relates to (release_and_maintenance.rst) probably
+   also belongs here somewhere
+
 Pull Requests
 =============
 

docs/docsite/rst/community/github_admins.rst

@@ -0,0 +1,29 @@
+GitHub Admins
+=============
+
+.. contents:: Topics
+
+GitHub Admins have more permissions on GitHub than normal contributors.  There are
+a few responsibilities that come with that increased power.
+
+
+Add and Remove Committers
+-------------------------
+
+The Ansible Team will periodically review who is actively contributing to Ansible to grant or revoke
+contributors' ability to commit on their own.  GitHub Admins are the people who have the power to
+actually manage the GitHub permissions.
+
+
+Change Branch Permissions for Release
+-------------------------------------
+
+When we make releases we make people go through a :doc:`release_manager` to push commits to that
+branch.  The GitHub admins are responsible for setting the branch so only the Release Manager can
+commit to the branch when the release process reaches that stage and later opening the branch once
+the release has been made.  The Release manager will let the GitHub Admin know when this needs to be
+done.
+
+.. seealso:: The `GitHub Admin Process Docs
+    <https://github.com/ansible/ansible/blob/devel/hacking/release-branches.rst>`_ for instructions
+    on how to change branch permissions.

docs/docsite/rst/community/index.rst

@@ -19,6 +19,7 @@ To get started, select one of the following topics.
    reporting_bugs_and_features
    how_can_I_help
    maintainers
+   release_managers
    communication
    other_tools_and_programs
 

docs/docsite/rst/community/release_managers.rst

@@ -0,0 +1,80 @@
+Release Managers
+================
+
+.. contents:: Topics
+
+The release manager's purpose is to ensure a smooth release.  To achieve that goal, they need to
+coordinate between:
+
+* Developers with Commit privileges on the `Ansible github repository <https://github.com/ansible/ansible/>`_
+* Contributors without commit privileges
+* The community
+* Ansible documentation team
+* Ansible Tower team
+
+
+Pre-releases: What and Why
+--------------------------
+
+Pre-releases exist to draw testers. They give people who don't feel comfortable running from source
+control a means to get an early version of the code to test and give us feedback. To ensure we get
+good feedback about a release, we need to make sure all major changes in a release are put into
+a pre-release. Testers must be given time to test those changes before the final release. Ideally we
+want there to be sufficient time between pre-releases for people to install and test one version for
+a span of time. Then they can spend more time using the new code than installing the latest
+version.
+
+The right length of time for a tester is probably around two weeks. However, for our three-to-four month
+development cycle to work, we compress this down to one week; any less runs the risk
+of people spending more time installing the code instead of running it. However, if there's a time
+crunch (with a release date that cannot slip), it is better to release with new changes than to hold
+back those changes to give people time to test between. People cannot test what is not released, so
+we have to get those tarballs out there even if people feel they have to install more frequently.
+
+
+What is Beta?
+~~~~~~~~~~~~~
+
+In a Beta release, we know there are still bugs.  We will continue to accept fixes for these.
+Although we review these fixes, sometimes they can be invasive or potentially destabilize other
+areas of the code.
+
+During the beta, we will no longer accept feature submissions.
+
+
+What is a Release Candidate?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In a release candidate, we've fixed all known blockers. Any remaining bugfixes are
+ones that we are willing to leave out of the release. At this point we need user testing to
+determine if there are any other blocker bugs lurking.
+
+Blocker bugs generally are those that cause significant problems for users. Regressions are
+more likely to be considered blockers because they will break present users' usage of Ansible.
+
+The Release Manager will cherry-pick fixes for new release blockers. The release manager will also
+choose whether to accept bugfixes for isolated areas of the code or defer those to the next minor
+release. By themselves, non-blocker bugs will not trigger a new release; they will only make it
+into the next major release if blocker bugs require that a new release be made.
+
+The last RC should be as close to the final as possible. The following things may be changed:
+
+    * Version numbers are changed automatically and will differ as the pre-release tags are removed from
+      the versions.
+    * Tests and :file:`docs/docsite/` can differ if really needed as they do not break runtime.
+      However, the release manager may still reject them as they have the potential to cause
+      breakage that will be visible during the release process.
+
+.. note:: We want to specifically emphasize that code (in :file:`bin/`, :file:`lib/ansible/`, and
+    :file:`setup.py`) must be the same unless there are extraordinary extenuating circumstances.  If
+    there are extenuating circumstances, the Release Manager is responsible for notifying groups
+    (like the Tower Team) which would want to test the code.
+
+
+Release Process
+===============
+
+The release process is kept in a `separate document
+<https://docs.google.com/document/d/10EWLkMesi9s_CK_GmbZlE_ZLhuQr6TBrdMLKo5dnMAI/edit#heading=h.ooo3izcel3cz>`_
+so that it can be easily updated during a release.  If you need access to edit this, please ask one
+of the current release managers to add you.