much easier • Projects are well managed with contributors in mind ◦ Easy to build & import in IDE • Contributions are properly attributed ◦ Commits, @author tags
skills, improve existing ones ◦ Apply the ideas from Spring projects to your own projects • Meet the people behind Spring and collaborate with them • Grow your reputation • Contributing is an empowering experience
for contributors ◦ README, CONTRIBUTING, CODE_OF_CONDUCT • Note the project’s active branches • Check out the issues marked for contribution ◦ JIRA roadmap, GitHub labels
Maven • Single-click builds that are easy on the newcomers ◦ ./gradlew build or ./mvnw clean install • Check out resources for contributors for more details ◦ Some projects have special build profiles, for example documentation builds
workflows ◦ Merge vs rebase • Note the preferred code style ◦ Check source repository for IDE config files • Use other people’s contributions as a reference • Reach out to the project maintainers or community ◦ Gitter or Stack Overflow
all branches of the original repository ◦ Some of them are not active, or not relevant for contributor • Deleting needless branches makes your fork easier to maintain
a note you’re working on it ◦ To help prevent duplicating efforts • Otherwise opening issue might be required • Pick the appropriate target branch ◦ Semantic versioning matters - semver.org • If in doubt about target branch consult the maintainers
appropriate code style ◦ Look for Eclipse formatter configuration files ◦ IntelliJ IDEA: Eclipse Code Formatter plugin • Create a dedicated feature branch for your changes - use target branch as base • Initially make your changes a single commit unless there’s a good reason to do otherwise
must if you change the code ◦ JUnit, AssertJ, Mockito, Spring Test support • Bug: add a test that reproduces the problem ◦ Check out the contributors resources • New feature: a substantial set of tests is expected ◦ Check the existing unit tests for similar/related functionalities
on writing good commit messages ◦ Check out the contributor resources ◦ chris.beams.io/posts/git-commit • Good commit message does you a favor when opening the PR ◦ Commit message is automatically used for PR description on GitHub
and easy to get running ◦ Check contributor resources for info on additional build profiles, like documentation • Contains additional checks, such as Checkstyle ◦ Import the IDE code style config ◦ Use Checkstyle plugin for your IDE • Tests the impact of your changes on entire project
CLA ◦ cla.pivotal.io has all the details ◦ The process in nearly automatic these days • Minor changes can skip some checks ◦ CLA not required - add “Obvious Fix” to the PR description ◦ Skip the Travis CI build - include “[ci skip]” in commit message
stuck or fail for transient reasons ◦ You can trigger the build again by closing and reopening the PR ◦ Or more elegantly using Git $ git commit --amend --no-edit && git push --force
if your PR is introducing new features • Often times you’ll be asked to rework your proposal • Don’t open a PR and walk away ◦ If unsure how to rework your proposal ask for help ◦ If you have no time to rework let the maintainers know
the existing PR - no need to close existing and open new one • You can simply push more commits to your PR branch • You can update the existing commit (force push is needed) $ git add . && git commit --amend --no-edit && git push --force
be patient ◦ It might get some time for maintainers to get to your PR • Your contribution was not accepted - don’t get discouraged ◦ If you’re active in the open source this will happen sooner or later :) • Your contribution was accepted - welcome to the club!
vpavic
kakehashi
oracle4engineer
bbrbbq
abemii
uhyo
ryosukeigarashi
kamina_zzz
eventhub
salaboy
amixedcolor
kevinliebholz
afnizarnur
lemiorhan
moore
eileencodes
brianwarren
lara
chriscoyier
ammeep
carmenintech
aki_iinuma
