Lessons learned contributing to EGit project
- Be careful with sources had been used on the way. You may be asked under what terms you received this material.
- Your contribution may be accepted not with all speed. Don’t expect rapid feedback on your bugs, patches, e-mails etc.
- Holes may be present in a contributor’s guide. Do you like nitpicking? Sometimes you may be forced to resubmit your patch due to a trivial style nit.
- When users download your sources, they must always just build. Always. Build. Without a single failing unit test. Programs with failing unit tests are difficult to contribute to, because you cannot easily determine if any change you made improved the program or not.
- Always open is a fundamental rule of open source, so internal conversations should be avoided at any cost. Unfortunately, right now you can’t reply to a comment posted via Gerrit using your e-mail client’s feature «reply to mailing list» so that it will be posted to the comment thread in Gerrit. I hope an incoming email gateway would be implemented in Google Gerrit, sooner or later.
- Conversations must be conducted as close to the code as possible. Tools like git format-patch, git am and Google Gerrit make this a no-brainer task.
- «Release early, release often» sounds as an easy goal but there is still no update site with a latest pre-build version(s) of EGit.