3 ms·

> I take my name off the reviewer list and it’s reassigned. How big is your team? We've got 4 developers on our team (and one lead), and require two signoffs f

by zadjii 4y ago

> I take my name off the reviewer list and it’s reassigned. How big is your team? We've got 4 developers on our team (and one lead), and require two signoffs for code changes. There's just not enough of us for something like that to work... right?

aftbit 4y ago
That doesn't sound like the best ratio to me, but I don't know what you are running or how good your deploy process is at catching issues. With a 4 person team, you are probably better off discussing risky/bigger changes as a whole team, and allowing 1 review for smaller, less risky changes with well defined rollback processes.
- carlmr 4y ago
  Also with a team so small you can't afford wasting it on meetings. You might need focus, i.e. non-meeting days, 3 days a week.
flamebreath447 4y ago
I work on similar sized teams, I introduce my PRs as stacked so they are extremely consumeable in very small bite-sized code changes and build on the last one reviewed.
- RussianCow 4y ago
  Do you use any special tools for this? I've heard of people "stacking" diffs in this way, but it seems like it would be clunky to review on GitHub.
  - return_to_monke 4y ago
    This is one of the features of (yes), Meta's sapling VCS. https://sapling-scm.com/docs/introduction/getting-started/ https://sapling-scm.com/docs/introduction/getting-started/
  - Dunedan 4y ago
    If you work directly in the source repository that works actually really well on Github (if everybody works on its own fork instead, you're unfortunately out of luck). When opening a pull request, you just select the branch the pull request should be based on to be the previous branch in your stack. If one of those pull requests gets merged, Github will automatically rebase the stacked on onto the base branch. This way every pull requests contains exactly the changes you want it to contain, while you're still being able to stack changes by opening multiple pull requests, with each one being based on the branch of the previous one.
  - kevingoslar 4y ago
    I use https://www.git-town.com/nested-feature-branches.html https://www.git-town.com/nested-feature-branches.html.
newaccount74 4y ago
So every change needs to be seen by 3 out of 5 people (assuming the lead also does code review)? That sounds a bit inefficient.

by zadjii 4y ago

aftbit 4y ago

That doesn't sound like the best ratio to me, but I don't know what you are running or how good your deploy process is at catching issues. With a 4 person team, you are probably better off discussing risky/bigger changes as a whole team, and allowing 1 review for smaller, less risky changes with well defined rollback processes.

carlmr 4y ago
Also with a team so small you can't afford wasting it on meetings. You might need focus, i.e. non-meeting days, 3 days a week.

flamebreath447 4y ago

I work on similar sized teams, I introduce my PRs as stacked so they are extremely consumeable in very small bite-sized code changes and build on the last one reviewed.

RussianCow 4y ago
Do you use any special tools for this? I've heard of people "stacking" diffs in this way, but it seems like it would be clunky to review on GitHub.
- return_to_monke 4y ago
  This is one of the features of (yes), Meta's sapling VCS. https://sapling-scm.com/docs/introduction/getting-started/ https://sapling-scm.com/docs/introduction/getting-started/
- Dunedan 4y ago
  If you work directly in the source repository that works actually really well on Github (if everybody works on its own fork instead, you're unfortunately out of luck). When opening a pull request, you just select the branch the pull request should be based on to be the previous branch in your stack. If one of those pull requests gets merged, Github will automatically rebase the stacked on onto the base branch. This way every pull requests contains exactly the changes you want it to contain, while you're still being able to stack changes by opening multiple pull requests, with each one being based on the branch of the previous one.
- kevingoslar 4y ago
  I use https://www.git-town.com/nested-feature-branches.html https://www.git-town.com/nested-feature-branches.html.

newaccount74 4y ago

So every change needs to be seen by 3 out of 5 people (assuming the lead also does code review)? That sounds a bit inefficient.