kevinheyer/bootstrap-vz
1
0
Fork 0
mirror of https://github.com/kevingruesser/bootstrap-vz.git synced 2025-10-07 17:40:30 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Note about changelog in contribution guidelines

Browse source
This commit is contained in:
Anders Ingemann 2014-05-08 23:16:00 +02:00
parent f50a8e66ce
commit 551b01ea27
1 changed files with 17 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
CONTRIBUTING.md
View file

@ -5,18 +5,20 @@ Do you want to contribute to the bootstrap-vz project? Nice! Here is the basic w
* Fork this repository. * Fork this repository.
* Make any changes you want/need. * Make any changes you want/need.
* Check the coding style of your changes using [tox](http://tox.readthedocs.org/), running `tox -e flake8` and * Check the coding style of your changes using [tox](http://tox.readthedocs.org/) by running `tox -e flake8`
fixing any warnings that may appear. This will be done again by and fix any warnings that may appear.
[Travis CI](https://travis-ci.org/andsens/bootstrap-vz) later when you send a pull request, so it's better if This check will be repeated by [Travis CI](https://travis-ci.org/andsens/bootstrap-vz)
you check this before. once you send a pull request, so it's better if you check this beforehand.
* If the change is significant (e.g. a new plugin, manifest setting or security fix)
add your name and contribution to the [changelog](CHANGELOG.md).
* Commit your changes. * Commit your changes.
* Squash the commits if needed. For instance, it is fine if you have multiple commits describing atomic units * Squash the commits if needed. For instance, it is fine if you have multiple commits describing atomic units
of work, but there's no reason to have many little commits just because of corrected typos. of work, but there's no reason to have many little commits just because of corrected typos.
* Push to your fork, preferable on a topic branch. * Push to your fork, preferably on a topic branch.
By this moment, there are two paths that you have to consider: From here on there are two paths to consider:
If you patch is a new feature, e.g.: plugin, provider, etc. then: If your patch is a new feature, e.g.: plugin, provider, etc. then:
* Send a pull request to the `development` branch. It will be merged into the `master` branch when we can make * Send a pull request to the `development` branch. It will be merged into the `master` branch when we can make
sure that the code is stable. sure that the code is stable.
@ -25,13 +27,15 @@ If it is a bug/security fix:
* Send a pull request to the `master` branch. * Send a pull request to the `master` branch.
Please try to be very descriptive about your changes when you write a pull request, stating what it does, why --
it is needed, what use cases do you think it would be useful, etc. You could as well be asked to rebase your
work on the current branch state, so it can be merged cleanly. Also, be in mind that if you push a new commit
to your pull request, we won't be notified just by this - that will happen only if you make a new comment on
the issue.
Be aware that your modifications needs to be properly documented and pushed to the `gh-pages` branch, if they Please try to be very descriptive about your changes when you write a pull request, stating what it does, why
it is needed, which use cases this change covers etc.
You may be asked to rebase your work on the current branch state, so it can be merged cleanly.
If you push a new commit to your pull request you will have to add a new comment to the PR,
provided that you want us notified. Github will otherwise not send a notification.
Be aware that your modifications need to be properly documented and pushed to the `gh-pages` branch, if they
concern anything done on `master`. Otherwise, they should be sent to the `gh-pages-dev`. concern anything done on `master`. Otherwise, they should be sent to the `gh-pages-dev`.
Happy hacking! :-) Happy hacking! :-)