Patch review
Jul. 30th, 2010 10:10 am![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png)
So, right now our major bottleneck in the dev process is code review! We're doing really well with patches being coded, and really well with bringing in new developers and getting them interested and working on things, but we've been having real problems finding people to do code review, and almost all the time it winds up being the people who are committing patches who do all the reviews.
This is a bad thing, for a few reasons: it means the committers burn out more quickly; everyone has different review styles, and notices different things, so having only one or two people doing the bulk of reviews leads to more things being missed; it slows down the turnaround time on commits; it means the committers are mostly working on reviewing and committing so they don't get as much time to code themselves; it means the committers feel rushed and pressured to get through the queue, because they know that nobody else is doing it, and that doesn't make for good work; and it means the rest of the dev team is losing out on the chance to learn from the process of reviewing someone else's code. I'd really like to see more peer review going on, with people reviewing each other, so that the committers have more of a chance to commit things that have already been reviewed by others instead of doing the bulk of the review themselves.
Ideally, I think we should be at around 60-70% peer review, with the remaining bits being committer review, and right now we're pretty much at 0%.
There are a few things I'd like to try to encourage people to do more peer reviewing, but before I do any of that, I figured I'd ask you guys some questions about doing reviews. Behind the cut is a poll, and I'd also love to hear any of your thoughts in comments. Poll answers are viewable in specific to nobody but maintainers of the comm, and if you have a comment that you'd like to leave, but don't feel comfortable doing so logged-in, anon commenting is enabled.
( Read more... )
This is a bad thing, for a few reasons: it means the committers burn out more quickly; everyone has different review styles, and notices different things, so having only one or two people doing the bulk of reviews leads to more things being missed; it slows down the turnaround time on commits; it means the committers are mostly working on reviewing and committing so they don't get as much time to code themselves; it means the committers feel rushed and pressured to get through the queue, because they know that nobody else is doing it, and that doesn't make for good work; and it means the rest of the dev team is losing out on the chance to learn from the process of reviewing someone else's code. I'd really like to see more peer review going on, with people reviewing each other, so that the committers have more of a chance to commit things that have already been reviewed by others instead of doing the bulk of the review themselves.
Ideally, I think we should be at around 60-70% peer review, with the remaining bits being committer review, and right now we're pretty much at 0%.
There are a few things I'd like to try to encourage people to do more peer reviewing, but before I do any of that, I figured I'd ask you guys some questions about doing reviews. Behind the cut is a poll, and I'd also love to hear any of your thoughts in comments. Poll answers are viewable in specific to nobody but maintainers of the comm, and if you have a comment that you'd like to leave, but don't feel comfortable doing so logged-in, anon commenting is enabled.
( Read more... )