I would have to disagree, because there's a logical fallacy in your reasoning here. I agree with your point that in addition to fixing a bug, there's also the

I would have to disagree, because there's a logical fallacy in your reasoning here. I agree with your point that in addition to fixing a bug, there's also the need to test, document, take account of maintainability, performance and coding standards and to do a lot more work that isn't quite so visible. And some of that burden is pushed onto the reviewers, testers and integrators of that work. However, none of this is a justification for making the contribution process baroque and opaque. I have noticed over the last 20 years or so that as a general rule the bigger the project, and the more closed the development process, the more baroque and opaque the contribution process is. Larger projects with more management layers seem to accrete unnecessary complexity and process, and generally behave in a more insular manner than smaller projects. I don't think things have to be this way. But I do think that keeping the processes simple, accessible and visible is important and that projects need to spend some effort upon keeping their projects open to external contributions. It's all too easy to adopt processes which work internally but deter and confound external contributions, and I think that should be something which project managers should be aware of and try to avoid doing out of short-term convenience.