Question

I’ve been practising with both the Android Framework and Revision Control Systems (Git) lately and I’ve made some modifications to the UI of an application I use often. It’s a small open source project and I’m curious what would be the best practice for submitting changes to such projects?
I’m sure it’s mostly dependent on the dev themselves, but are there any no-no’s or areas (code or otherwise) to avoid when submitting changes? Should I contact the dev first or just submit the modifications etc.?

Answer 1

This depends on the project.

You’re mentioning Git in your question. If the project is already using Git, you could publish your own forked Git repository somewhere like GitHub or BitBucket. Better, if the initial project is also on GitHub or BitBucket, fork it from there and open a pull request.

For other revision control systems, you may have to submit a patch directly via their issue tracking system.

This being said, don’t neglect the human aspect of this. Most OSS maintainers will welcome patches, but you have to remember that they need to understand what your modifications do and why you’ve made them, whether it’s a bug fix or additional feature. Pull requests on their own are appropriate for straightforward modifications (e.g. changing only a few lines of code with a clear purpose), but not necessarily great if further discussions are required.

Check whether there is a dev. mailing list for that project (or fall back to the users list, or at worse the maintainer’s e-mail address) and send an e-mail describing what you’re suggesting. The area where you’re contributing might not be the area of expertise of the current team of developers. As always, clarity and courtesy are necessary in those cases. In general, however good your idea is, avoid to dump a patch that’s going to modify plenty of files in various places without having discussed it a little with the developers.

In addition, it’s worth checking the licence agreements. Some projects will expect you to agree to give your contribution to the project, so that it can be re-licensed later on if required.