We encourage and appreciate contributions by all users e.g. in the form of
bug reports, bug fixes, adding features, providing examples, improving
documentation, etc.

In this section we will describe both the workflow of the contributor and
the maintainer. If you have suggestions which may make the workflow easier
for either side, please do not hesitate to Contact Us.

Now here’s the part people usually don’t figure out until it’s
too late - do not commit any changes to your fork’s master
branch! The master branch of your fork is always kept in sync
with the origina repo’s master branch (from remote).

It is good practice to make your changes to your fork in a separate branch
(we typically call this a feature branch).

If you don’t know how to make a branch, there’s quite a bit of good
tutorials and guides. For example this one.

Warning

Before you start changing the code look at our Sign-off
procedure. Any commits to the source code must contain a
sign-off statement which ensures that Steinwurf ApS holds the
copyright of all the source code.

To decrease the amount of formatting corrections, please try to follow our
conventions:

We never allow commits directly on the master branch. Changes can go to the
master branch after our buildbot has confirmed that the changes work on all
supported platforms.

When you create a pull request for the first time, you can choose the
branch where the commits should be applied. At first, you should choose the
master branch, because the feature branch does not exist in the
original repository. Our maintainers will create a feature branch for your
changes and notify you.

Unfortunately, GitHub does not allow you to change the base branch of a pull
request so once the feature branch is ready on the main Kodo repository you
need to create a new pull request using the new feature branch as the base.

The maintainer may now comment on your changes before they can be merged.

If the maintainer pushes commits to the feature branch for you to review,
you can pull them in by (assuming you already set an upstream):

To accept changes to the our repositories, we ask that you sign over the
copyright of your changes to us. This is similar to what is done for the
SQLite project.

We require this in order to maintain clear title to the source code and
prevent the introduction of code with incompatible licenses or other
entanglements that might cause legal problems for us and our users. In
order to manage this, you can choose to use either of the two methods below: