<div dir="ltr">Hey guys,<div><br></div><div>There are two main aspects to the article:</div><div><br></div><div>1. Rate of contributions dwindles down</div><div>2. When you try to contribute, you get turned down (<a href="http://rachelnabors.com/2012/04/of-github-and-pull-requests-and-comics/">http://rachelnabors.com/2012/04/of-github-and-pull-requests-and-comics/</a>)</div><div><br></div><div>I wanted to focus on the second aspect, and note that I think we're doing rather well in that regard. The patch that the article autor proposes is that possible grounds for patch rejection can be as follows:</div><div><br></div><div><div>- The patch has an obvious security vulnerability</div><div>- The project has a pre-existing, documented, design decision or policy against the feature</div><div>- The patch violates a pre-existing, documented backwards compatibility policy. In this case there should be a focus on merging the patch in a way compliant with the policy, like in the next major version, etc.</div><div>- There is actual evidence, not mere speculation, that the patch has significant downsides. For example, benchmarks showing degraded performance on an important platform.</div><div>- The patch causes test failures</div></div><div><br></div>And the comment: "Notably absent from my list of objections is any concern for project stability."<div><div><br></div><div>Maciej</div></div></div>