34 lines
1.6 KiB
Markdown
34 lines
1.6 KiB
Markdown
# Contributing
|
|
|
|
Thank you for reading this! This document has some notes on contributing to the
|
|
development of Retrospring.
|
|
|
|
## Reporting bugs
|
|
|
|
Before submitting an issue please check if there is already an existing issue.
|
|
If there is, please add any additional information or give it a 👍 reaction.
|
|
|
|
When submitting an issue please describe the issue clearly, including how to
|
|
reproduce the bug, which situations it appears in, what you expect to happen,
|
|
what actually happens, and what platform (browser and operating system) you are
|
|
using. We find screenshots (for front-end issues) very helpful.
|
|
|
|
## Pull Requests
|
|
|
|
1. Fork it (https://github.com/Retrospring/retrospring/fork)
|
|
2. Create your feature branch (`git checkout -b feature/new`)
|
|
3. Commit your changes (`git commit -am 'Add some feature'`)
|
|
4. Push to the branch (`git push origin feature/new`)
|
|
5. Create a new Pull Request
|
|
|
|
We love pull requests! We are very happy to work with you to get your changes
|
|
merged in, however please keep the following in mind.
|
|
|
|
* Please use the core team standard of `feature/*` or `bugfix/*` branch naming.
|
|
* Using these branch prefixes tags the Pull Requests with the appropriate labels for release categorization.
|
|
* Adhere to the coding conventions you see in the surrounding code.
|
|
* If you include a new feature also include tests, and make sure they'll pass.
|
|
* Before submitting a pull-request, clean up the history by going over your
|
|
commits and squashing together minor changes and fixes into the corresponding
|
|
commits. You can do this using the [interactive rebase](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_changing_multiple) command.
|