Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in-review label: how and when to use it #48

Closed
nelsonic opened this issue Jan 23, 2017 · 5 comments
Closed

in-review label: how and when to use it #48

nelsonic opened this issue Jan 23, 2017 · 5 comments
Labels
discuss Share your constructive thoughts on how to make progress with this issue enhancement New feature or enhancement of existing functionality help wanted If you can help make progress with this issue, please comment!

Comments

@nelsonic
Copy link
Member

nelsonic commented Jan 23, 2017

The in-review label is reserved for the team member / QA reviewing the Pull Request code/change. The reviewer applies the label to communicate with the rest of the team that they are actively reviewing the PR and to avoid duplication of effort.
We used to require reviewers to write a comment on the PR (typically a 👀 :eyes: emoji) to indicate that they were reviewing the PR, but we decided that using a label instead of a comment was clearer (especially to non-technical team members/stakeholders) and worked well for us.

only the reviewer should apply the in-review label. this will start the clock on their Timer. 👍

Process Automation enhancement help wanted

Once the pull request has been merged @dwylbot 🤖 will remove the in-review label from the Pull Request and apply the please-test label. 🛎
Additionally/Optionally @dwylbot 🤖 will parse the commit messages in the PR for any issue numbers and apply the please-test label to those issues too. ✨

@nelsonic nelsonic added discuss Share your constructive thoughts on how to make progress with this issue enhancement New feature or enhancement of existing functionality help wanted If you can help make progress with this issue, please comment! labels Jan 23, 2017
@iteles
Copy link
Member

iteles commented Jan 23, 2017

Is this the in-review label as used in the PRs?

On issues, teams have tended to move issues from in-progress to in-review once they have opened a PR on it, to ensure that they can easily identify what has already been worked on in the backlog and what still requires work. This might not be the best way of doing this, so I wanted to bring it up here to make sure the differentiation was able to be clarified.

@nelsonic
Copy link
Member Author

When a story is "code complete" by the Developer(s) they will remove the in-progress label.
I would suggest the story gets the awaiting-review label applied. see: #49

ideally the act of assigning the PR to Reviewer(s) will do all the necessary label changing.

@iteles
Copy link
Member

iteles commented Jan 23, 2017

Perfect 👍

@iteles
Copy link
Member

iteles commented Feb 2, 2017

Note: I disagree that dwylbot should automatically apply a 'please test' label. Often there is a lag between a merge and a deployment and we've had POs complain before that things have been assigned to them prematurely (it just looks to them like the issues hasn't been fixed) which is an ineffective use of everyone's time.

I'll post a suggested solution asap but thoughts welcome!

@iteles
Copy link
Member

iteles commented Mar 19, 2017

@nelsonic Label added to repo and description added to readme with reference to this issue. Can we close it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Share your constructive thoughts on how to make progress with this issue enhancement New feature or enhancement of existing functionality help wanted If you can help make progress with this issue, please comment!
Projects
None yet
Development

No branches or pull requests

2 participants