jonashub/team-docs
1
0
Fork 0
forked from docs/team-docs
Code Pull requests Activity

Wordiness on multiple MR paragraphs fixed

Browse source
This commit is contained in:
hank L 2023-04-19 07:39:44 +00:00
commit 2bfa68f7e6
1 changed files with 3 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

8
modules/ROOT/pages/organizational/workflow.adoc
View file

@ -1,6 +1,6 @@
= The Docs Workflow organization
Fedora Documentation Team <https://discussion.fedoraproject.org/tag/docs>
:revdate: 2023-04-18
:revdate: 2023-04-19
[abstract]
This workflow organization is relevant for Docs members or people who want to become Docs members.
@ -40,11 +40,9 @@ This is an internal task of Fedora Docs that is not a change, fix or update of a
Each issue ticket and each open Merge Request has to be labeled additionally with one of these three labels. The type labels do not change during the workflow.
Beyond a state label and a type label, issue tickets and merge requests can be additionally labeled as "good first issue": You want to contribute to Fedora Docs? This is your opportunity. Feel free to comment in one of these issues that you want to take over! This is a good way to get in touch with Fedora Docs and the team, and to find out if you want to become yourself a member.
Beyond a state label and a type label, issue tickets and merge requests can be additionally labeled as "good first issue": You want to contribute to Fedora Docs? This is your opportunity. Feel free to comment in one of these issues that you want to take over.
Furthermore, there is an additional label for Merge Requests that could possibly affect more than one branch, which would mean that they require follow-up Merge Requests or follow-up cherry-picks (the latter is preferred). The *multiple MR likely* label ensures that all affected branches are identified and updated, and that Merge Requests that have this label are not merged without ensuring that the follow-ups are conducted and not forgotten (once accepted, a Merge Request disappears from the Open Merge Requests list, and remaining follow-ups are likely to become forgotten).
Therefore, the *multiple MR likely* label ensures that all affected branches needs to be identified in advance to accepting any merge, whereas accepting the Merge Request and conducting the related cherry-picks have to be done at once. In short, you need to ensure that the Merge Request does not disappear from the Open Merge Request page until the update of all affected branches is ensured.
Furthermore, there is an additional label for Merge Requests that could possibly affect more than one branch, which would mean that they require follow-up Merge Requests or follow-up cherry-picks (the latter is preferred). The *multiple MR likely* label ensures that all affected branches are identified and updated, and that Merge Requests that have this label are not merged without the MR review.
== How issue tickets and Merge Requests are created