In this blog post I describe how I will handle future collaboration of my open source projects in regards of each projects overall quality and features. This blog post should make clear why I maybe rejected your pull request.
Recently I got worried about the quality of my open source projects. Especially for the projects I got collaborators. For some of my open source projects on GitHub I accepted code from other people. But some of the code is not the standard I use.
I do not want to reject people on GitHub. When someone wants to collaborate on an open source project of mine I always feel special. The person maybe put a vast amount of time into a feature for a project I created on GitHub. So I cannot reject the code. Even if this makes the quality of a project bad?
What’s the most valuable thing someone has? It’s time. Even if someone had put a vast amount of time and energy into a new feature of my project, I’m (maybe) still in the position to reject a pull request. I never thought about this before, but maybe I should more often reject bad code for my open source projects. It’s not only the other persons time which gets wasted. It’s also my time. It’s my time get wasted if I randomly accept pull requests and I have to rewrite the accepted code at some later point in the lifetime of a project. It’s maybe bullshit code I should not have accepted in the first place. Saving time by rejecting bad quality code? Or saving everyones time by deactivating the Pull Request function on GitHub?
Outlines
Each project should have a clear outline of planned features. Which features to a project need? What’s planned for next versions? What will the project NEVER cover. If the README of each project covers the answers to these questions maybe new users and new collaborators have a better understanding of what could be a possible pull request.
A good example for outlines is my Keylogger project on GitHub. This Keylogger will never be anything but a Keylogger. Because of this simple rule I rejected several feature requests. [1][2] Not all projects have a clear outline like that. For most of the projects even I don’t know what they could become in the future. Writing the outlines down in the README will help the users and me.
But it’s not only about the outlines of a project and its features. Most of the time I care about the code quality. It’s most important for all my projects. Rejecting code should happen more often in favor of the code quality. This will disappoint people, but it is also a good training for beginners. So rejecting code should not only be seen as bad. The requester should have a really good reason why he is not sticking to the project outlines.
Conclusion
For future pull requests I will make a very detailed code review. The code quality has to be very good to fit my standards. Even if this means that someone may be mad at me, but this is only in favor of a project’s quality. Rather one is mad for some time, than more people are mad about the overall project quality. I’m not perfect, so maybe your standards will not fit my standards.
Further, I will define outlines for each project in the README file. This will help users and collaborators and me.
