mirror of
https://github.com/qgis/QGIS.git
synced 2025-06-25 00:04:25 -04:00
Updated Changelog Workflows (markdown)
Charlie
parent
03a656f94a
commit
ad975220c0
@ -1,66 +1,54 @@
|
||||
## Introduction
|
||||
|
||||
blah blah
|
||||
This workflow outlines the processing steps taken by changelog maintainers to ensure that pull requests providing new functionality (i.e. Feature updates) are properly documented in order hat they may be adapted and published in the changelog for each release of QGIS
|
||||
|
||||
## General Workflow
|
||||
|
||||
1) The changelog maintainer (currently GitHub user: zacharlie) is added to the ‘Community’ GitHub group which has triage rights
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2) The changelog maintainer will read each Pull Request (PR) that has a **Feature** label as it comes in as per the following URL:
|
||||
|
||||
https://github.com/qgis/QGIS/pulls?q=is%3Aopen+is%3Apr+label%3AFeature
|
||||
https://github.com/qgis/QGIS/pulls?q=is%3Aopen+is%3Apr+label%3AFeature
|
||||
|
||||
In the comments section, they will make a comment to the author if the feature is not clear / well described. We would be grateful if the PR gatekeepers could hold back on merging Feature PR’s that have issues, do not have a **Changelog** tag applied.
|
||||
|
||||
3) Once the changelog maintainers are confident that the feature functionality is described well enough that a changelog entry of the expected quality standard may be produced, they will apply the **Changelog** label to the PR as per the following example.
|
||||
|
||||
|
||||
|
||||
After the **Changelog** tag has been added, the PR maintainers should feel free to merge the PR if they are happy with it.
|
||||
|
||||
> Note that the English description doesn’t need to be perfect (it is understand that English may not be the mother tongue of many developers submitting features), however it is important that the functionality is well described. The English description will be tidied up the in step 6 below.
|
||||
|
||||
4) **Changelog** tagged entries which have been merged will be harvested to the Changelog site regularly. This is done using the ingestion tool as shown in the screenshot below:
|
||||
|
||||
|
||||
|
||||
5) After closed Changelog PRs have been harvested, we will list the harvested entries on GitHub via the following URL:
|
||||
|
||||
https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aclosed+label%3AChangelog
|
||||
|
||||
First, the additional label on GitHub called ‘ChangelogHarvested’ will be applied to indicate that the entry has been harvested into.
|
||||
|
||||
Next, the **Changelog** label will be removed. This will prevent the same PR being reharvested (by the tool outlined in step 4) in subsequent harvest runs on the changelog platform, whilst retaining the relevant label required to indicate the PR contains a changelog entry.
|
||||
|
||||
6) The entry will then be tidied up on the changelog site ready for the release. Additional volunteers from the changelog maintainers team will help improve the clarity and consistency of the entries on the changelog site. The entry should follow the conventions that are described in the "Conventions for changelog entries" section below. The goal here is to massage the description etc. to fit into our changelog entry form:
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
In the comments section, they will make a comment to the author if the feature is not clear / well described. We would be grateful if the PR gatekeepers could hold back on merging Feature PR’s that have issues, do not have a **Changelog** tag applied. Once the **Changelog** tag has been added, the PR maintainers should feel free to merge the PR if they are happy with it.
|
||||
|
||||
|
||||
Note that the English doesn’t need to be perfect (we are understanding that English may not be your mother tongue), the important thing is that the functionality is well described - we will tidy up the English in step 6 below.
|
||||
|
||||
|
||||
|
||||
3) Once the PR description is good, the changelog maintainer will add the ‘Changelog’ tag to it as per the example below.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
4) Once the PR is merged, we will regularly Harvest the ‘Changelog tagged entries to the Changelog site. This is done using the ingestion tool as shown in the screenshot below:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
5) After the closed Changelog PRs have been harvested, we will go here:
|
||||
|
||||
https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aclosed+label%3AChangelog
|
||||
|
||||
First we will apply the additional tag on GitHub called ‘ChangelogHarvested’.
|
||||
Next remove the Changelog tag.
|
||||
|
||||
This will prevent the same PR being reharvested in subsequent harvest runs on the changelog platform.
|
||||
|
||||
|
||||
6) The entry will then be tidied up on the changelog site ready for the release. Additional volunteers from the changelog maintainers team will help improve the clarity and consistency of the entries on the changelog site. The entry should follow the contensions that are described in the "Conventions for changelog entries" section below. The goal here is to massage the description etc. to fit into our changelog entry form:
|
||||
|
||||
|
||||
|
||||
|
||||
7) When the release comes near we need the paid bug fixing entries added under 'Notable fixes'. This is managed by Andreas Neumann.
|
||||
|
||||
|
||||
|
||||
|
||||
8) After the changelog is finalised, notify Richard who will then pull the changelog to the QGIS web site.
|
||||
|
||||
|
||||
## More on tagging
|
||||
|
||||
We will add the tag when we want to ingest it so we will have 3 states basically:
|
||||
We will add the **Changelog** tag when we want to ingest it so we will have 3 states basically:
|
||||
|
||||
1) Feature tag - not ready for ingestion in Changelog
|
||||
2) Feature tag + Changelog tag + PR Merged - ready for ingestion
|
||||
@ -69,4 +57,15 @@ We will add the tag when we want to ingest it so we will have 3 states basically
|
||||
|
||||
## Conventions for changelog entries
|
||||
|
||||
Once published, the changelog entries will be available at https://qgis.org/en/site/forusers/visualchangelogs.html
|
||||
|
||||
The entries will therefore need to comply with the associated stylesheets and conventions utilised with previous releases.
|
||||
|
||||
The following list outlines some basic guidelines for ensuring the entry content is of the required standards:
|
||||
|
||||
- Not contain header tags such as ```<h1>``` as these will display on the changelog site as TOC links
|
||||
- Media should be explicitly added to the entry (downloaded to local and uploaded with changelog tool)
|
||||
- Have a single thumbnail icon
|
||||
- Be categorised appropriately
|
||||
- Language should generally be considered neutral
|
||||
- Content should be articulate and concise
|
||||
Loading…
x
Reference in New Issue
Block a user