Discussion:  On-Release CHANGELOG Assembly
> This issue is related to #1542 and #1544.

In #1542, we discussed two possible workflows for keeping CHANGELOGs up-to-date.  The first one is that after each merged PR, the maintainers and collaborators add a new entry to the CHANGELOG.  The second one is that contributors always add their preferred entries to the CHANGELOG themselves.  Both have their disadvantages.

The first workflow is very time-consuming.  After each PR, the maintainers and collaborators would have to figure out how the introduced changes could be summarised best and need to add the resulting entry to the CHANGELOG.  Obviously, this requires working through the changes once again in case that the PR's description should not be very informative.  The time required for this cannot be used to develop new major features of the project and will, hence, slow down the development in the long term.

The second workflow challenges this disadvantage by handing the responsibility for the creation of the new CHANGELOG entry over to the respective contributors.  They will then not only submit their changes but also add a brief summary directly to the CHANGELOG file.  The disadvantage here is the risk of Merge Conflicts.  Large projects like [Lapce](https://github.com/lapce/lapce) suffer from this notably.  Let us therefore consider the following example.  Three contributors A, B, and C submit PRs to a project with all three PRs originating from the same repository state.  All contributors edit the CHANGELOG by adding appropriate entries, this is, they edit the very same line.  When A's PR gets merged at first, the PRs of B and C will receive Merge Conflicts as now, they attempt to overwrite A's CHANGELOG entry with their own entries.  After resolving the conflicts, both PRs can be merged again with, say, B's PR being the next one merged.  C would have to resolve the resulting Merge Conflicts, again.  In the long term, this does not only slow down the development, it might be also very discouraging for the contributors.

The solution to the disadvantages of both workflows is the following third one.  The CHANGELOG is an artifact which is neither edited by the maintainers and collaborators nor by the contributors.  A software tool will take care about shelving in the new entries.  These are stored as unique files, named fragments, in a central storage.  On release, the main maintainer instructs the software to collect all fragments and to insert them into the CHANGELOG.  The software will sort them by category and add a title for the new version, as well.  My suggestion is to introduce this workflow for Moe, as well.

For this purpose, there are plenty FOSS tools available, most of them only accept ReStructuredText CHANGELOGs -- such as the one I proposed in #1544.  I worked with [Scriv](https://github.com/nedbat/scriv), so far, which also accepts Markdown CHANGELOGs (which tend to become a little ugly due to some rendering issues, thus the RST version is also for Scriv preferably).  The software is licensed MIT and written in Python 3.  To install, run `pip3 install scriv`.  The fragments are stored in the directory `changelog.d/` in the repository root, by default, into which the CLI will insert the new fragments by calling `scriv create --edit`.  This will open a template for a new fragment in Moe, one just needs to add the information.  The file name will consist of a timestamp, the user name and the current branch making the fragment unique in order to prevent Merge Conflicts.  When the new version is ready for release, one maintainer calls `scriv collect` such that Scriv will paste all fragments into the CHANGELOG.  It will create the version header for the Keep a Changelog convention, as well, in addition to a hook for an optional table of contents.

With Scriv, the workflow will become as follows.  The contributor submits the PR as usually.  When the PR was created, the contributor commits the fragment; the current style of the CHANGELOG demands to know the number of the respective PR.  When merged, the changes will be applied and the new fragment is added to the fragment storage.  On release, the fragments will be collected and removed after pasting their contents to the CHANGELOG, leaving an empty directory to be filled again for the next release.  This procedure would reduce the maintenance effort for the CHANGELOG to a sane minimum while ensuring the entries to be complete and informative.

My suggestion is to setup Scriv for Moe.  I would therefore suggest to add the configuration to #1544.  @fox0430, do you agree?