... |
... |
@@ -83,11 +83,11 @@ Check the templates used at BuildStream: |
83
|
83
|
* bug template: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/.gitlab/issue_templates/bug.md
|
84
|
84
|
* Merge request template: https://gitlab.com/BuildStream/buildstream/blob/master/.gitlab/merge_request_templates/bst_merge_request.md
|
85
|
85
|
|
86
|
|
-## Technical/engineering tasks: best practices.
|
|
86
|
+### Technical/engineering tasks: best practices.
|
87
|
87
|
|
88
|
88
|
These are the best practices that are applied to Gitlab at BuildStream in relation with bugs and tasks. Please read them carefully and try to apply them.
|
89
|
89
|
|
90
|
|
-### Open/create a technical issue
|
|
90
|
+#### Open/create a technical issue
|
91
|
91
|
|
92
|
92
|
In order to open a new task the best place is the green button at this page: <https://gitlab.com/BuildStream/buildstream/issues>. Please follow these considerations:
|
93
|
93
|
* Use the default template.
|
... |
... |
@@ -108,7 +108,7 @@ In order to open a new task the best place is the green button at this page: <ht |
108
|
108
|
* The MR associated with the ticket. Please do not forget this.
|
109
|
109
|
* If your issue remains unprocessed after a few days/weeks, please ask through the project mailing list about it. It should be the exception but it might have been overlooked or remain unnoticed.
|
110
|
110
|
|
111
|
|
-### Update an engineering task / ticket
|
|
111
|
+#### Update an engineering task / ticket
|
112
|
112
|
|
113
|
113
|
Assuming the bulk of the work on engineering tasks takes places on Merge Requests (code), it is strongly recommended that you follow these advices:
|
114
|
114
|
* Assign the ticket to you when you start working on it. More than one person can be assigned to a single task.
|
... |
... |
@@ -118,13 +118,13 @@ Assuming the bulk of the work on engineering tasks takes places on Merge Request |
118
|
118
|
* Update the ticket when a relevant event takes place. In any case, update the ticket every couple of days.
|
119
|
119
|
* This is very important for others to follow up your work.
|
120
|
120
|
|
121
|
|
-### Close an engineering task
|
|
121
|
+#### Close an engineering task
|
122
|
122
|
|
123
|
123
|
(coming soon)
|
124
|
124
|
|
125
|
|
-## Bugs: best practices
|
|
125
|
+### Bugs: best practices
|
126
|
126
|
|
127
|
|
-### Open/create a bug
|
|
127
|
+#### Open/create a bug
|
128
|
128
|
|
129
|
129
|
In order to open a new bug the best place is the green button at this page: <https://gitlab.com/BuildStream/buildstream/issues>. Please follow these considerations:
|
130
|
130
|
* Use the Bug template. Choose it from the template menu when creating a new bug.
|
... |
... |
@@ -141,7 +141,7 @@ In order to open a new bug the best place is the green button at this page: <htt |
141
|
141
|
* Further considerations:
|
142
|
142
|
* Please refer to the considerations made for issues since they also apply to this case.
|
143
|
143
|
|
144
|
|
-### Update a bug
|
|
144
|
+#### Update a bug
|
145
|
145
|
|
146
|
146
|
Assuming the bulk of the work on bugs takes places on Merge Requests (code), it is strongly recommended that you follow these advices:
|
147
|
147
|
* Assign the bug to you. More than one person can be assigned to a single bug.
|
... |
... |
@@ -155,13 +155,13 @@ Assuming the bulk of the work on bugs takes places on Merge Requests (code), it |
155
|
155
|
|
156
|
156
|
These are the different policies that the project applies to merge requests.
|
157
|
157
|
|
158
|
|
-### Close a Bug
|
|
158
|
+#### Close a Bug
|
159
|
159
|
|
160
|
160
|
(coming soon)
|
161
|
161
|
|
162
|
|
-## Merge requests (MR): best practices
|
|
162
|
+### Merge requests (MR): best practices
|
163
|
163
|
|
164
|
|
-### Open/create a merge request
|
|
164
|
+#### Open/create a merge request
|
165
|
165
|
|
166
|
166
|
Please read carefully the following policies before opening a new merge request. The best place to create a new merge request is this page: <https://gitlab.com/BuildStream/buildstream/merge_requests>. Please follow these considerations:
|
167
|
167
|
* Use the default template.
|
... |
... |
@@ -177,7 +177,7 @@ Please read carefully the following policies before opening a new merge request. |
177
|
177
|
* If you want to notify somebody about the merge request, please add his/her name as first comment, starting by the character "@". Try to avoid naming people for notification reasons in the merge request description field.
|
178
|
178
|
* If your merge request remains unprocessed for over a week, please ask through IRC (#buildstream in irc.gonme.org) about it. It should be the exception but it might have been overlooked, remain unnoticed or the default reviewer is overloaded.
|
179
|
179
|
|
180
|
|
-### Update a merge request
|
|
180
|
+#### Update a merge request
|
181
|
181
|
|
182
|
182
|
It is strongly recommended that you follow these advices:
|
183
|
183
|
* Assign the Merge Request to you when you start working on it. Please remember than more than one person can be assigned to the MR.
|
... |
... |
@@ -185,6 +185,12 @@ It is strongly recommended that you follow these advices: |
185
|
185
|
* If the MR is in progress, please assign to it the label "Doing", removing the "ToDo" label if present.
|
186
|
186
|
* every MR should be related in the description field to at least one engineering task or bug. Please check this is the case.
|
187
|
187
|
* Update the MR when a relevant event takes place.
|
|
188
|
+
|
|
189
|
+#### Close a Merge Request
|
|
190
|
+
|
|
191
|
+(coming soon)
|
|
192
|
+
|
|
193
|
+## Roadmap policies
|
188
|
194
|
|
189
|
195
|
## Suggest improvements or additions to the BuildStream policy
|
190
|
196
|
|
... |
... |
@@ -194,6 +200,3 @@ If the suggestion refers to how to manage tickets, bugs or merge requests or any |
194
|
200
|
|
195
|
201
|
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.
|
196
|
202
|
|
197
|
|
-### Close a Merge Request
|
198
|
|
-
|
199
|
|
-(coming soon)
|