Re: [BuildStream] Proposal: label name change: review -> verify

[Agustín Benito Bethencourt <agustin benito codethink co uk>]

Hi,

On Wednesday, 25 July 2018 13:06:36 CEST Phillip Smyth wrote:
> On Tue, Jul 24, 2018 at 09:49:59AM +0200, Agustín Benito Bethencourt via 
Buildstream-list wrote:
> > Hi,
> >
> > On Monday, 23 July 2018 17:23:34 CEST Jim MacArthur via Buildstream-list
> >
> > wrote:
> > > On 23/07/18 16:05, Agustín Benito Bethencourt via Buildstream-list 
wrote:
> > > > Dear BuildStream fans,
> > > >
> > > > there seem to be a confusion about what the label Review which is
> > > > described in the policy[1] as a state label:
> > > >
> > > > "Review: items that are under review once the developer or contributor
> > > > has
> > > > finished it."
> > > >
> > > > I propose the change the label name from "Review" to "Verify" avoid
> > > > any
> > > > misunderstanding.
> > > >
> > > > The Status scale would be:
> > > >
> > > > * Backlog: default state on Gitlab so no label needed.
> > > > * Todo: processed elements that should be done in the future.
> > > > * Doing: WIP
> > > > * Verify: items that has been finished but somebody else should go
> > > > over
> > > > them to check them before closing them.
> > > > * Closed: items that has been processed and canceled, finished or no
> > > > longer
> > > > apply. Default state on Gitlab so no label needed.
> > > >
> > > > In summary, a ticket should be in Verify state when its acceptance
> > > > criteria
> > > > has been met and somebody else needs to check that it is the case.
> > > >
> > > > Please do not mistake it with... this ticket includes a MR that needs
> > > > to
> > > > be
> > > > reviewed. Calling the attention of the reviewers in order to have your
> > > > new
> > > > code reviewed should be made through the MR, not the related issue.
> > >
> > > I'm fine with this, but can I suggest we start using the 'review' label
> > > on MRs instead to indicate that they need review? I find it very useful
> > > to be able to filter current issues for this to find work to review and
> > > would like to continue doing so.
> >
> > I have suggested this in the past informally. I think that as a way for
> > reviewers to list those MR that are on their plate is a good approach.
> >
> > A complementary one would be to assign a MR to them so the receive a
> > notification and it is even easier to list the MR. With this second
> > approach, once reviewed, if the developer needs to act, the reviewer
> > could assign him back the MR.
> >
> > In other words, use the ticketing system to ping the right person instead
> > of using the chat.
>
> I agree with this idea,
> It'd also be nice if there was some way to assign it to multiple people,
> so the person actively working on it could keep track of it as an item they
> were working on, whilst also having it assigned to a reviewer,
> But i'm not sre if that's even possible

The reason why we are not actively promoting the usage of the Assignee field is 
because we want to be relaxed when it comes to community members with the 
usage of Gitlab. The idea is to pick the tasks instead of assigning them.

The fact that we are not promoting the usage of this field actively does not 
mean you cannot use it. It is just that we should not expect everybody else to 
use it. Some people are using already.

Best Regards


-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html