Check the coding style of your changes using tox by running tox -e flake8
and fix any warnings that may appear.
This check will be repeated by Travis CI
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.

Commit your changes.

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.

Push to your fork, preferably on a topic 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, 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. Please take a look at the
documentation section to see how to do that.

The following guidelines should serve as general advice when
developing providers or plugins for bootstrap-vz. Keep in mind that
these guidelines are not rules , they are advice on how to better add
value to the bootstrap-vz codebase.

The outcome of a bootstrapping process should never depend on settings
specified elsewhere.

This allows others to easily reproduce any setup other people are running
and makes it possible to share manifests.
The official debian EC2 images for example can be reproduced
using the manifests available in the manifest directory of bootstrap-vz.

For end users, this guideline minimizes the risk of errors. Any
required input would also be in direct conflict with the previous
guideline that the manifest should always fully describe the resulting
image.

Additionally developers may have to run the bootstrap
process multiple times though, any prompts in the middle of that
process may significantly slow down the development speed.

The bootstrapper should only need as much setup as the manifest requires¶

Having to shuffle specific paths on the host into place
(e.g. /target has to be created manually) to get the bootstrapper
running is going to increase the rate of errors made by users.
Aim for minimal setup.

Exceptions are of course things such as the path to
the VirtualBox Guest Additions ISO or tools like parted that
need to be installed on the host.

If a run() function checks whether it should do any work or simply be
skipped, consider doing that check in resolve_tasks() instead and
avoid adding that task altogether. This allows people looking at the
tasklist in the logfile to determine what work has been performed.

If a task says it will modify a file but then bails , a developer may get
confused when looking at that file after bootstrapping. He could
conclude that the file has either been overwritten or that the
search & replace does not work correctly.

Avoid creating complicated run() functions. If necessary, split up
a function into two semantically separate tasks.

This allows other tasks to interleave with the control-flow and add extended
functionality (e.g. because volume creation and mounting are two
separate tasks, the prebootstrapped plugin
can replace the volume creation task with a task of its own that
creates a volume from a snapshot instead, but still reuse the mount task).

Only add stuff to the BootstrapInformation object when really necessary¶

The json-schema may be verbose but it keeps the bulk of check work outside the
python code, which is a big plus when it comes to readability.
This only applies as long as the checks are simple.
You can of course fall back to doing the check in python when that solution is
considerably less complex.