Thanks a lot for considering contributing to the Bike Data Project. Following these guidelines helps to communicate that you respect the time of the developers managing and working on this open source project. In return, they reciprocate that respect in addressing your issue, assessing changes and helping you finalize your pull requests.
For something that is bigger than a one or two line fix:
- Create your own fork of the repository
- Do the changes in your fork
- If you like the change and think the project could use it:
- Be sure you have followed the code style for the project.
- Send a pull request to the develop branch summarizing which changes you have been made.
If you have a different process, let us know first.
Small contributions such as fixing spelling errors, where the content is small enough to not be considered intellectual property, can be submitted by a contributor as a patch
As a rule of thumb: changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following:
- Spelling / grammar fixes
- Typo correction, white space and formatting changes
- Comment clean up
- Bug fixes that change default return values or error codes stored in constants
- Adding logging messages or debugging output
- Changes to 'metadata' files like .gitignore, build scripts, etc.
- Moving source files from one directory or package to another
If you find a security vulnerability, do NOT open an issue. Email [email protected] and/or [email protected] instead.
In order to determine whether you are dealing with a security issue, ask yourself these two questions:
- Can I access something that's not mine, or something I shouldn't have access to?
- Can I disable, enable or modify something for other people?
If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us at [email protected] and/or [email protected].
When filing an issue, make sure to use one of the available issue templates. If the templates do not cover your issue you can use a blank issue.
The core team looks at Pull Requests on a regular basis. After feedback has been given we expect responses in an acceptable time. After some time we may close the pull request if it isn't showing any activity.
If the pull request looks good and has been accepted by multiple core team members, it can get merged into the develop and/or master branch(es).
This project uses a standard gitflow, features are being developed on a branch named from this template: feature/<what-my-branch-will-do>. Once the feature is done and that you already tested it locally & extensively, create a pull request on the develop branch.
- On this project we use the Effective Go code formatting
- Try to regulary reformat code using the official GoFmt tool
Try to explain clearly what this commit is doing. There is no particular conventions to commits. Use extra descriptions if the message is too long.
Pick labels that globally says what your PR is doing, if it is fixing a bug, adding a feature, etc. If an issue is being resolved in the PR, please link that issue so that it can get closed.