Commit 921b10e1 authored by Laurence Urhegyi's avatar Laurence Urhegyi

Update BuildStream_policies.md

amends some wording to be clearer and more accurate
adds some points around the impact scale that users can assign themselves
corrects some typos 
parent bcc7eae0
......@@ -25,15 +25,10 @@ and value all contributions to the project!
### Milestones
[Milestones](https://gitlab.com/groups/BuildStream/-/milestones) on Gitlab denote
time-bound periods: we are using milestones to structure releases and events.
We are using Gitlab's [Milestones](https://gitlab.com/groups/BuildStream/-/milestones)
to help us structure and plan the content for releases and events.
See all group level milestones [here](https://gitlab.com/groups/BuildStream/-/milestones).
Note: milestones are not to be confused with [Epics](https://docs.gitlab.com/ee/user/group/epics)
which allow you to group sub tasks into an overall goal.
Epics are currently not available for us to use in this version of Gitlab.
### Labels
......@@ -41,35 +36,38 @@ Epics are currently not available for us to use in this version of Gitlab.
filter tickets (ie, 'issues' in Gitlab terminology) in useful ways.
Labels add complexity and effort as they grow in number, so the ideal approach
is to have the minimum possible but to use them consistently. Sadly, we currenlty have
far too many labels, so if you want to add a new one, please do discuss this the [mailing
is to have the minimum possible but to use them consistently. Sadly, we currently have
far too many labels, so if you want to add a new one, please discuss this on the [mailing
list](https://mail.gnome.org/mailman/listinfo/buildstream-list) first.
We have both [global scale labels](https://gitlab.com/groups/BuildStream/-/labels) and
We have both [group level labels](https://gitlab.com/groups/BuildStream/-/labels) and
[BuildStream project specific labels](https://gitlab.com/BuildStream/buildstream/labels).
When raising an issue, please consider which labels are appropriate:
When raising an issue, please consider which labels are appropriate. We have the following labels:
* Topic labels: each repository has its own labels that allow you to structure tickets per topic. For example, there's a 'Documentation' label for tasks related to documentation.
* Topic labels: mainly used for tasks rather than bugs. Each repository has its own labels that allow you to structure tickets per topic. For example, there's a 'Documentation' label for tasks related to documentation.
* Severity scale: please apply the below in order to get the attention of the core development team, as these labels are prioritized in weekly meetings:
* Impact scale: Please apply the below if the bug/feature/task has a high impact on you as a user - this will be evaluated by the core development team and may be modified.
* No label: the bug/feature/task is infrequent or hard to reproduce and the impact on the users is low or hard to determine.
* High Impact: the bug/feature/task takes place frequently or is a recurrent one and has a significant impact on users everyday or key work.
* Status scale: please see below re the Gitlab Issue Boards.
* Severity scale: please do *not* worry about assigning these labels - all tickets are processed by the core development team [on a weekly basis](https://mail.gnome.org/archives/buildstream-list/2018-October/msg00064.html) and they will apply the below labels in order to prioritize.
* No label: unprocessed item, no or low priority.
* Important: default severity for processed items that should be executed/considered.
* Urgent: to pay attention in the immediate future when possible.
* Critical: topics that require attention immediately when possible.
### Issue Boards
[Issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html) allow anybody interested in BuildStream to visualise and manage issues in a simple way.
There are [Global level boards](https://gitlab.com/groups/BuildStream/-/boards/580444?milestone_title=BuildStream_v1.1>&=) and
[BuildStream project specific boards](https://gitlab.com/BuildStream/buildstream/boards/580451?milestone_title=BuildStream_v1.1>&=).
There is a drop down menu allowing you to select every available board. The most relevant to most people is the [Status-All Board](https://gitlab.com/BuildStream/buildstream/boards/134373).
See the
[BuildStream project specific boards](https://gitlab.com/BuildStream/buildstream/boards/580451?milestone_title=BuildStream_v1.1>&=) for details.
There is a drop down menu allowing you to select every available board. For a view of the currently WIP items see the [Status-All Board](https://gitlab.com/BuildStream/buildstream/boards/134373).
Issues start life in the ``Backlog`` column by default, and we move them into
``ToDo`` when we aim to complete them soon. ``Doing`` is only for when an item is
``ToDo`` when it is agreed that the work should be done. ``Doing`` is only for when an item is
currently being worked on. When on the Board view, dragging and dropping an issue from
column to column automatically adjusts the relevant labels.
......@@ -102,9 +100,7 @@ We have two templates for issues:
- If you plan to work on an issue, please:
- self-assign the ticket
- ensure the ticket is in the ``ToDo`` column of the [Status-All Board](https://gitlab.com/BuildStream/buildstream/boards/134373) if you aim to
work on it soon but are not yet working on it, and
the ``Doing`` column if you are working on it currently.
- ensure the ticket is in the ``Doing`` column of the [Status-All Board](https://gitlab.com/BuildStream/buildstream/boards/134373) if you are working on it.
- Please note that Gitlab issues are for either 'tasks' or 'bugs' - ie not for
long discussions (where the mailing list is a better choice) or for ranting,
......@@ -112,12 +108,16 @@ We have two templates for issues:
## Roadmap policies
Coming soon...
## Suggest improvements or additions to the BuildStream policy
## Suggest improvements or additions to BuildStream policies
For any suggestions related to policies for hacking on BuildStream code, please submit an MR to [CONTRIBUTING.rst](https://gitlab.com/BuildStream/buildstream/blob/master/CONTRIBUTING.rst).
If the suggestion refers to coding or hacking the BuildStream code related policies, please create a MR to the technical documentation: <https://gitlab.com/BuildStream/buildstream/tree/master/doc/source>
If the suggestion refers to how to manage tickets, bugs or merge requests or any other topic not directly related with coding, please create a MR to this policy instead of editing this wiki page.
If the suggestion refers to how to manage tickets, bugs or merge requests or any other topic not directly related with coding, please create a MR to this policy instead of editing this wiki page: <https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/BuildStream_policies.md>
Or, alternatively, please always free to send any proposal to the mailing list:
You can always send the proposal to the <mailto:buildstream-list@gnome.org> mailing list if any of the options above fits or you are unsure about what to do.
<mailto:buildstream-list@gnome.org>
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment