Author: boyska Date: To: tails-dev Subject: Re: [Tails-dev] Proposal: use the "Reviewer" field in GitLab MRs
>intrigeri <intrigeri@???> writes: >> A few months ago, GitLab Inc. open-sourced the "Reviewer" feature for
>> Merge Requests.
>>
>> This allows keeping track _independently_ of:
>>
>> - Who's responsible for bringing the MR to completion: the Assignee.
>>
>> - Who's responsible for reviewing the MR: the Reviewer.
>>
>> Some teams have been experimenting with this workflow in the last
>> months, instead of our previous — and still documented — workflow in
>> which we would assign a MR to its Reviewer. The feedback that came my
>> way has been entirely positive so far.
yay, it's very nice to be able to easily distinguish MRs in which you
are the "author" and MRs in which you are the reviewer.
>> I think it's now time to make a decision and adjust either our
>> documented process or our actual practices to match it.
>>
>> I propose we start using the "Reviewer" field in MRs, as described
>> above and in the GitLab documentation.
sure!
Zen Fu: >Another thing that could be explicitely documented is whether a reviewer
>should/could merge code after a review or not. This may differ from team
>to team because not always the assignee has privileges to merge. Maybe
>we could explicitely say when we expect the reviewer to merge? Or maybe
>the MR should then be re-assigned to someone that can actually merge? I
>don't think we need to make this very complex, but as it's a question
>that has popped up for me I'm raising it here.
I don't think we need to dive into full details here (per-team
conventions, plus written words on the issue itself can help!) but my
understanding is that setting $person as reviewer means that $person
needs to do something on this MR.
It's typically review, but in some cases it might be merging or what
not: in such cases, a comment explaining what $person is asked to do is
probably enough.
