The approach described in Multics Development Process applies to Multics for the simulator environment. The actual procedures for carrying out the process have changed somewhat. The current process, as I know it, is this:
We have two particularly relevant mailing lists: dps8m-users and dps8m-developers. The first is for the general Multics/DPS8 community, while the latter is more for developers of either the emulator or Multics. When someone from either community finds a bug in the currently released Multics (or perhaps an earlier release), he/she is encouraged to enter a ticket in the Multics ticket system. It is located here:
https://multics-trac.swenson.org/
(The ticket system requires a password, provided on the 
Multics Wiki.)
Usually, someone in the "community" decides to fix the issue, or scans the ticket list looking for something to fix. In addition, folks in the community come up with "improvements" or "new features" for Multics. These are usually discussed on the mailing lists first, and then an MCR is written. In order to get an MCR number assigned, the developer goes to the SVE Multics system (sve-multics.duckdns.org) (this is due to historical use for this purpose) and in the "MCRs" forum on that system, enters a post in the forum with the "next" available MCR number. This claims the number.
MCRs, whether proposed, approved, waiting for audit, audited, or installed are listed in Post-Honeywell MCRs, MCRs since 2015.
For any MCRs that require more depth, an MTB is written and circulated on the mailing list.
MTBs are also listed in Post-Honeywell MTBs, MTBs since 2015.
No installations are performed in the main integration system, Gold Hill Multics (GHM, at multics.swenson.org), until there are MCRs (and possibly MTBs) to document them, and until the corresponding MCR is approved.
The MCR approval process is pretty ad-hoc at the moment. The MCR is distributed (via links on the above MCR page and/or via email attachments) to the dps8m-users and dps8m-developers mailing lists. Frequently, the multicians mailing list is also used. Approval is done by informal comments in the mailing lists. When we determine that either there have been no objections by the "due date" (this has only been used once, by Gary Dixon, recently) or that there have been a sufficient number of approvals, the MCR is considered "approved". Its status is updated on the https://multics-wiki.swenson.org/index.php/MCRs page to reflect that is has been approved (but not yet audited or installed on GHM).
The developer implements the changes on whatever Multics system he/she chooses and when ready, solicits the dps8m-users and dps8m-developers mailing lists for an auditor. The audits are done on the GHM system, so code is usually transferred there, if it was not created there. The >sysbuild>MCRs>MCRnnnnn directory is used for all MCRs and usually there is an "audit" subdirectory used for the auditor. The auditor doesn't start auditing until the proper history comments (using the history_comment (hcom) command) are recorded. This records the author and the fact that the MCR has been approved.
The auditor then audits the code and may have a discussion with the developer until the two are mutually happy with the result and any changes made to the copy of the software in the audit sub-directory. For all new programs or any changes that have documentation impact, an info segment is created or updated and possibly Multics manual errata are created. All of these are part of the audit directory and are audited.
Once the audit is done, the auditor updates the history comments to reflect the completion of this task.
The next step is for the system librarian (currently Eric Swenson) to install the changes in the system libraries. The installer chooses the next sequential "change number" and records this in the install field and updates the history comments to include an "install" field, with the Multics release number and "change number" recorded. For example, MR12.6f-0023 would represent the 23rd install for MR12.6f. (We are probably going to start using the MR release number of the current release, rather than the next release soon, since picking the proposed "next" release name presupposes that we know what release number we're going to use in advance. For example, we've decided that the next Multics release will be 12.7 and that we will stop the practice of using letters, such as with MR12.6f and MR12.6g). However, before we made that decision, we performed installs with MR12.6g-NNNN as the install tag. It would have been better to use the current release, which is unambiguous).
The standard update_seg (us) tool is used for all installations. This updates the Installations.log and Installations.info segments in the >sysbuild>MCRs directory. Recently, a new tool written by Gary Dixon, mbuild, is used to prepare an exec_com used with update_seg, obviating a lot of manual steps in the build/install process. The "comment" used in the Installations.log and Installations.info segments includes the "install tag" (release number + change number) for tracking purposes.
Any tickets closed by virtue of an installation are so-marked in the ticket system.
Installations continue in this vein until such time as the "community" decides to create a new Multics release. Up until this time, the changes are only installed on GHM. (Although we've not frequently done this, we can make patch tapes for other users in the community to try changes out before the next Multics release).
Once we decide to create a new release, Eric Swenson prepares the release. This involves creating the System Release Bulletin (SRB) and System Installation Bulletin (SIB) using the format established when Honeywell developed releases. These are authored with compose, but we generate a PDF version as well for distribution outside Multics. These documents are included on the release tapes (more on this shortly).
The system_book_ is also generated using tools Eric Swenson has developed. This document has the identical format as it did historically. It is generated from bind maps and hardcore checker output. It used to be generated with the help of python scripts run on host computers, but in the next Multics release, new tools, implemented in PL/1, will be used to generate the data required to create the system book, and also, to put together the actual system book document.
Once all the required artifacts for a system release are created and stored in the right places, the system librarian/system release custodian (currently Eric Swenson), uses the library_cleanup command to clean up all the temporary artifacts produced by the update_seg tool from all the installations, and then creates system release tapes (e.g. MR12.7_MULTICS, MR12.7_EXEC, MR12.7_LDD, and MR12.7_MISC). Eric Swenson QAs the tapes by doing upgrade and fresh installs with the latest release emulator. Once he is satisfied that the release is "ready", he distributes the tapes online (and records them in the Multics WIKI -- https://multics-wiki.swenson.org/index.php/Main_Page). He also notifies the "community" via the dps8m-users, dps8m-developers, and multicians mailing lists. The release is considered "beta" at this point, and the community is encouraged to try out the release. Sometimes a subset of the community is solicited to test out the release before the release is made public.
Once the release is made public, the release cycle starts over again.