Contribution Guide
All of neo4j-ogm is Licensed under Apache v2.0. By contributing you agree:
- To license the work under Apache v2.0.
- That you have the right to assign this license - this is your original work, or you have permission from the owners to contribute.
Of course this goes without saying, nonetheless:
We provide a friendly environment that welcomes everyone, regardless of gender, age, disability, physical appearance, race, religion, national origin, sexual orientation or gender identity.
Please be respectful of and welcoming to your fellow users and contributors.
All files MUST include the copyright header found in the repository: Copyright-Header.txt. Your help replacing any incorrect headers with this canonical one, as we propagate this requirement across the code-base, is greatly appreciated. We recommend the use of a code snippet with the abbreviation 'ogm_header' to automate the insertion of this notice.
If you want, you can use a filter that will automatically check the header presence and include it if it is not already there for every file you add or modify. To enable this behavior you should run this two commands in your working copy directory:
git config filter.ogmheader.smudge 'cat'
git config filter.ogmheader.clean '`git rev-parse --git-dir`./Copyright-Header.txt'This two config entries register the filter that will add the right header for you.
- Create a feature branch (core team) or fork (outside contributions are most welcome). Branch names should be lowercase, and may link to a GitHub issue. For example
feature/issue-322. - When you're happy submit a pull request to start the merge process.
Code Reviews serve the following purposes:
- Help improve design
- Spot potential problems
- Promote shared ownership - teach co-contributors about new parts of the code-base.
If conducting a review will support any of the above goals, it is valuable, otherwise unnecessary ceremony can be avoided. Core contributors may submit simple bug-fixes and config changes directly.
- Leave feedback or questions. Repeat as many times as necessary.
- Merge the feature branch or fork. Ensure to squash multiple commits into a single one, with meaningful comment.
- Delete the feature branch.
- Current, bleeding edge development occurs on master. Upon release a new micro, minor or major branch is created.
- Maintenance branches are labeled with semantic versions, with an 'x' in place of the micro version. Example: 1.1.x or 2.0.x. Upon release these are tagged with the hard version number.