Glorious sunny ride in the Kent hills this morning with Glenn, nice humble chap but I’ve known him long enough to know of his psychopathic love of extreme endurance events …
Me: “Weren’t you training for something big last time I saw you? When we started heading back home you went on to do an 8 hour ride.”
Glenn: “Oh yeah, I just came back from Mexico – did the Quin out there.”
Me: “WHOA! How did it go?”
Glenn: “Umm, pretty good actually – I won.”
Holy crap, I just rode 110km with the Quintuple Ironman world champion!
In the Free and Open Source software worlds, it seems that a lot of people with good intentions don’t understand how to contribute efficiently and effectively to upstream software projects. I say this based on personal experience: I sometimes receive patches to projects I maintain, where despite good intentions and a perfectly valid goal (e.g. a bug-fix or feature implementation), the patches are fundamentally flawed in a variety of ways. So unfortunately I cannot accept them without negatively impacting the quality or maintainability of the project. And I don’t even maintain any wildly popular projects.
It is possible to spend a lot of money on training to learn how to avoid these mistakes, and also many well-organized projects already provide good documentation on how to contribute, such as the Linux kernel and git. However, these documents typically mix up generic advice with project-specific advice. In this post I would like to present a list of generic advice on how to write patches which have the maximum chance of being accepted quickly and with gratitude rather than resentment!
Continue reading '7 principles for contributing patches to software projects'»