Author: Zen Fu Date: To: intrigeri, The Tails public development discussion list Subject: Re: [Tails-dev] Proposal: use the "Reviewer" field in GitLab MRs
intrigeri <intrigeri@???> writes: > Hi,
>
> 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.
>
> 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.
>
> Any issue with that?
No issues with that.
In one recent occasion, intrigeri removed himself (as a reviewer) after
finishing a review of a MR of mine. I thought this was interesting from
my "assignee" point of view because I knew intrigeri was finished with
the review and I felt I had a mechanism to ask him for a 2nd round of
review (if needed) without having to explicitely @mention him.
Not sure if this should be default or documented, but flaggin it as
possibly useful for some workflows.
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.
