We love contributions! Thank you so much for investing time in making our toolset better! We have gathered some hints to make the process smoother for both sides.
We have certain coding convention in place, please have a look at code-settings repository.
Typically invoking mvn clean package would be enough. If that is not working on you machine please tell us about it and file an issue.
To make your experience even easier, we have provided Maven Wrapper, so you don’t have to bother about proper version. It comes bundled with the repo. In order to use it please invoke ./mvnw clean package instead.
Here are bunch of simple rules to follow:
-
Keep PR small, focused and coherent. This will result with
-
faster reviews
-
shorter route to upstream
-
less chance of breaking other things
-
-
Please add ref|fixes #issue when apropriate
-
Single commit pr issue upstream
Everyone will be able to review your changes. Discussions will be raised, code samples will be shown, experiences will be shared. Everything is part of the review process.
When being reviewed, please consider the following aspects:
-
Answer to questions and comments that will come.
-
Don’t take it personally. Nobody is doing it in order to make you feel bad or let you uncomfortable among other developers.
-
Keep calm and accept 'critique/suggestions' as it’s intended; to improve our common code base
-
Always be humble. Learn from your mistakes.
-
Don’t discourage 'off-topic/wider' discussions, rather route them to the right place
-
public mailing list
-
new issue etc (if new Issue is created, reference it in the comment on the original so people can follow the thread)
-
-
Make sure you fully understand the other alternatives before choosing one of them or keeping the solution you’ve provided. If you did not fully understand why somebody asked you to change something, ask for explanations and/or examples. When in doubt see 5 Whys Principle.
Feedback is one of the most difficult and sensitive processes in groups. It is easy to hurt people with criticism, but false compliments are also unhelpful. Compliments often make us too complacent, while criticism damages our self-esteem and can lead us to make unwise choices
The Tschapeller and Kyogenus Collection
This quote is just perfect to explain the delicacy of a pull request review: not too rough, nor too lenient.
You should make a habit out of helping your colleagues to ship great features and quality code as they should help you to do the same. Reviewing Pull Requests isn’t something that we should be doing in our spare time or when we are idle - it is part of your daily workflow. And remember that giving your attention and time to review the work of someone else is the greatest proof that you care about his work. We should not just approve pull requests blindly. In order to write the most valuable review possible, we have to point out actionable problems.
Here are some suggestions which you can find useful:
-
Look out for code smells in the code that should be removed to avoid future problems with the code.
-
Share, whenever possible, different solutions for a given problem which could simplify and improve the code base.
-
Commits in a Pull Request should be meaningful on their own. Comment about better commit messages and point to relevant documentation where necessary.
-
Appreciate the quality of the work of your team.
-
Try to take the most of out the Github and Markdown when reviewing code: for highlighting snippets, doing references between commits and other issues and calling other developers to join you in the review.
-
Create ad-hoc tasks so they won’t get lost
-
Don’t be afraid of asking for explanation when necessary. Many times the discussions generated by a Pull Request can result in important improvements in the projects.