From 446fe332928a8c79c34fae957761b9ef9dd2b5a2 Mon Sep 17 00:00:00 2001 From: Charlie <64078329+zacharlie@users.noreply.github.com> Date: Sun, 17 Jan 2021 16:06:45 +0200 Subject: [PATCH] Updated Changelog Workflows (markdown) --- Changelog-Workflows.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Changelog-Workflows.md b/Changelog-Workflows.md index 4323ccb..83719ac 100644 --- a/Changelog-Workflows.md +++ b/Changelog-Workflows.md @@ -73,6 +73,7 @@ The entries will therefore need to comply with the associated stylesheets and co The following list outlines some basic guidelines for ensuring the entry content is of the required standards: +- Changelog entries are created by migrating data from merged pull requests onto the changelog platform. This process will attempt to scrape the media and comments from the *initial* post. The original Pull Request is available from the entry editing page under the **Github PR url** field, and should be reviewed to ensure that *all* relevant media and commentary from the pull request is included in the changelog entry. - The feature title should be unique. Pull requests often use "tags" to automatically manage elements in the workflow such as adding the **[Feature]** label to the element title. All such elements should be removed, and the title should properly convey the new functionality introduced. - Each entry should be categorised appropriately. By default, all newly imported entries will be included in the "General" category, however only entries that truly belong in the general category should be categorised as general by the time of publication. - Content should be articulate and concise. Details from the pull request relating to developer specific content or items specifically for the documentation team can be removed. Some information on the feature utilisation is suitable, however it should not be verbose. @@ -83,7 +84,7 @@ 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. -- 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. +- 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. @@ -93,7 +94,7 @@ The QGIS developers have been increasingly adding loads of new functionality wit First make sure you've signed up with an account at https://changelog.qgis.org -Then, in order to get "edit" access to the changelogs, you will need to get in touch with the changelog maintenance team. Simply send an email to charles[at]kartoza.com or tim[at]kartoza.com and express your interest. +Then, in order to get "edit" access to changelog entries, you will need to get in touch with the changelog maintenance team. Simply send an email to charles[at]kartoza.com or tim[at]kartoza.com and express your interest. Once you've been assigned the correct permissions, you will find the link to the latest release changelog at the bottom of the home page.