Updated Changelog Workflows (markdown)

Changelog-Workflows.md

@@ -48,11 +48,13 @@ Click the image above to play a YouTube video containing a walk through by Charl
    ![image](https://user-images.githubusercontent.com/178003/87296792-3437d400-c4ff-11ea-8754-1017e2397612.png)
 
 
-7) When the release comes near, the paid bug fixing entries added under 'Notable fixes' will need to be added. This is managed by Andreas Neumann.
+7) Entries may be reviewed and edited from within the *General* section, but should only be assigned to a category once the content is publication-ready in order to easily segregate the records which have or have not undergone some form of review.
+
+8) When the release comes near, the paid bug fixing entries added under 'Notable fixes' will need to be added. This is managed by Andreas Neumann.
 
    ![image](https://user-images.githubusercontent.com/178003/87296304-76ace100-c4fe-11ea-8eae-d73a59471e05.png)
 
-8) After the changelog is finalised, changelog maintainers will notify Richard, who will then pull the changelog to the QGIS web site.
+9) After the changelog is finalised, changelog maintainers will notify Richard, who will then pull the changelog to the QGIS web site.
 
 ## More on tagging
 
@@ -84,10 +86,14 @@ The following list outlines some basic guidelines for ensuring the entry content
 - Special characters should be avoided. Where relevant, move special characters like parenthesis and extraneous description elements from the entry title and into the description body.
 - Media should be explicitly added to the entry (downloaded to local and uploaded with the changelog tool).
 - Language should generally be considered neutral, however developer comments or embellishments are permitted within reason. American English is the preferred standard for spelling and grammar.
+- A historical context, or past tense, should be preferred when writing entries. Remember that PRs are written in the context of introducing neew functionality, whereas changelog entries are referring to features that have already been merged.
 - In some instances, especially with complex functionality, additional details or media on the feature may be discussed within the comments of the original PR on GitHub, which should be reviewed where relevant and included in the changelog entry.
 - References to oneself should be changed to group pronouns (i.e. 'I' becomes 'we')
 - Each developer tends to have different styles and standards for the structure and format of the entry content. Where possible, we should endeavour to keep things as consistent with the other entries as possible.
 - In some instances, a feature may be refactored from the original work of an author and merged by core maintainers. This is typically denoted by a ```Supersedes #1234``` message. In these instances, changelog maintainers will need to try review the content from the original PR for changelog materials, and include some information that identifies the contributions of original authors.
+- Note that in many instances, additional context, media, updates, or additional information is available from the PR link and only the initial commentary is captured to the changelog platform, which can be enhanced with the material available from GitHub.
+- Merging entries may make sense in some instances where a large body of work has been segregated into multiple distinct PRs. The context for these entries is managed by reviewing the functionality history on GitHub.
+- Some PRs are also written in the context of awaiting a functionality that exists at the time of release. They may refer to various components or changelog entries that have a better frame of reference considering the current context. These references need to be removed or updated to ensure consistency.
 
 ## Get involved