Andrew Straw wrote:
I also want to point out that a formal code review process that is open (such as a web gui) encourages participation by people who may not feel they have the time or abilities to write new code, but would feel comfortable commenting on a patch sitting in front of them. I think it new developers could be fostered this way, too.
Great idea! Let's have review/mentoring processes to assist new-comers. I'm all for that. I would like to move those people who are timid at first to the point of being willing to dive in and get their hands dirty. I suspect my view is a bit organic for some, but I've encouraged people for a long time to commit code with as much documentation and testing as can be provided. Then, let the process of further documenting and using that code "harden" it rather than a "review" process. If we feel that there have been too many "buggy-commits" then what are examples of that? I think the switch to NumPy and the integration of ndimage did bring in some "less-reviewed" code with API changes that were possibly too hurried. But, that was a time-problem again. Is imposing an extra burden on the developer really going to solve that problem more than just a willingness to allow your own code to be critiqued and being willing to speak up when you see specifics you disagree with. I don't see this discussion as review or not review. Open source *will* be reviewed. It's just "when." On the question of whether or not you make the code available until you can guarantee someone else has looked at it, I come down on the side of "make it available" so that other people will look at it when it becomes interesting to them. Tools that let us monitor the results of commits (buildbots, dashboards, automatic emails, etc...) are much more valuable in my mind than (difficult-to-quantify and establish) processes that try to prevent any problems. More tools please is fundamentally what I say to the question of formal review... -Travis