executablebooks
Team policy around requesting reviews and assigning to issues
GitHub has a few features to track "assignment" on issues and PRs. This can make it easier to know where to focus attention. Right now, we don't have any official processes around what it means when you are "assigned" an issue or a PR, so it's hard to know how to use these signals effectively. I think it might help us if we defined a team practice so that we all know what to expect.
Given that we all act relatively independently, what if we took an approach like the following:
- Any team member can request a PR review from another team member. If you're requested for review, try to give feedback within a few days, or make a comment in the PR that you don't have time to get to a review within a few days.
- When team members plan to actively work on something in the near future, assign yourself to that issue. This could be used in conjunction with the Team Activity Board, so that it's clear who wishes to work on what.
In the future, we might consider practices for assigning others to issues, but I'm not sure how to do this right now given that we all have very independent workflows and amounts of bandwidth to work on EBP directly, so that's why I thought we'd stick with "self-assign issues" for now.
@choldgraf I like both suggestions, and actively miss being able to assign myself to issues that I am active on. Having a policy of assign yourself, and not assign others is a good one to adopt I think. If a conversation results in someone picking up an issue, they can then self-assign.
Another process that I have been adopting recently with @chrisjsewell and @fwkoch is getting in touch and doing 10min walk throughs directly discussing the changes in addition to my own reviews of the changes. I think this certainly helps with the context switching and can help with not getting lost in the noise of github notifications.
