About Nepomuk Seiler

Nepomuk Seiler is a information sience student at the Ludwigs-Maximilians-University Munich. He uses Scala for machine learning tasks and web development with play. Also he provided some small contributions to the Eclipse community.

Open Source Projects – Between accepting and rejecting pull request

Lately I have done a lot of work for the sbt-native-packager project. Being a commiter comes with a lot of responsibilities. You are responsible for the code quality, supporting your community, encouraging people to contribute to your project and of course providing an awesome open source product.

Most of the open source commiters will probably start out as a contributor by providing pull requests fixing bugs or adding new features. From this side it looks rather simple, the project maintainer probably knows his/her domain and the code well enough to make a good judgement. Right?

 
 
This is not always the case. The bigger the projects get, the smaller the chance gets one contributor alone can merge your pull requests. However there’s a lot you can do to make things easier! I’m really glad a lot of contributors already do a lot of these things, but I wanted to write down my experience.

Provide tests

This is obvious, right? However tests are so much more than just proving it works or proving it’s fixed. Tests are like documenation for the maintainers. They can see how the new features work or what caused the bug. Furthermore it gives the maintainer confidence to work on this feature/bug fix himself as there’s already a test which checks his work.

Provide documentation

If you add a new feature then add a minimal documentation. A few sentence what does this, how can I use it and why should I use it are enough. It makes life a lot easier for maintainers judging your pull request, because they can try it out very easily themselves without going through all of your code at first.

Be ready for changes

To maintain a healthy code base with a lot of contributors is a challenge. So if you decide to contribute to an open source project try to stick to the style which is already applied in the repository. This applies to the high abstraction level to the deep bottom of low level code.
And if you don’t then be prepared to change your code as the maintainers have to make sure the code can be easily understood by everybody else. Sometimes it’s hard not to take this personally and we try to be very polite. However sometimes corrections are necessary.

There’s an easy way to avoid all of this…

Small commits, early pull requests

Start small and ask early. Write comments in your code, use the awesome tooling most of the code hosting sites provide like discussions or in-code-comments. Providing a base for discussions is IMHO the best way to get things done. You can discuss what’s good and bad, if the approach is correct or not. You avoid a lot work, which might  not be useful or out of scope and the maintainers don’t have to feel bad about rejecting a lot of work.

Tell us more!

A lot of open source projects where created for a specific need, but the nature of an open source project leads sometimes to an extension of this specific need and you add more features. Tell us what you do with it! The maintainers (hopefully) love there
project and are amazed by the things you can do with it. Write blog posts, tweets or stackoverflow discussions to show your case.

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply


eight × = 16



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books