<h2>Contributing through a forked repository<aclass="headerlink"href="#contributing-through-a-forked-repository"title="Permalink to this headline">¶</a></h2>
<p>We always need more eyes and hands on the code. Even if you don’t feel confident with tackling a
control instructions for detailed instructions.</p>
<p>Once you have a fork set up, you can not only work on your own game in a separate branch, you can
also commit your fixes to Evennia itself. Make separate branches for all Evennia additions you do -
don’t edit your local <codeclass="docutils literal notranslate"><spanclass="pre">master</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">develop</span></code> branches directly. It will make your life a lot easier.
generally be done against the <codeclass="docutils literal notranslate"><spanclass="pre">master</span></code> branch of Evennia, while new features/contribs should go into
the <codeclass="docutils literal notranslate"><spanclass="pre">develop</span></code> branch. If you are unsure, just pick one and we’ll figure it out.</p>
<h2>Contributing with Contribs<aclass="headerlink"href="#contributing-with-contribs"title="Permalink to this headline">¶</a></h2>
<p>While Evennia’s core is pretty much game-agnostic, it also has a <codeclass="docutils literal notranslate"><spanclass="pre">contrib/</span></code> directory. The <codeclass="docutils literal notranslate"><spanclass="pre">contrib</span></code>
directory contains game systems that are specialized or useful only to certain types of games. Users
are welcome to contribute to the <codeclass="docutils literal notranslate"><spanclass="pre">contrib/</span></code> directory. Such contributions should always happen via a
<li><p>If you are unsure if your idea/code is suitable as a contrib, <em>ask the devs before putting any
work into it</em>. This can also be a good idea in order to not duplicate efforts. This can also act as
a check that your implementation idea is sound. We are, for example, unlikely to accept contribs
that require large modifications of the game directory structure.</p></li>
<li><p>If your code is intended <em>primarily</em> as an example or shows a concept/principle rather than a
working system, it is probably not suitable for <codeclass="docutils literal notranslate"><spanclass="pre">contrib/</span></code>. You are instead welcome to use it as
part of a [new tutorial][tutorials]!</p></li>
<li><p>The code should ideally be contained within a single Python module. But if the contribution is
large this may not be practical and it should instead be grouped in its own subdirectory (not as
loose modules).</p></li>
<li><p>The contribution should preferably be isolated (only make use of core Evennia) so it can easily be
dropped into use. If it does depend on other contribs or third-party modules, these must be clearly
documented and part of the installation instructions.</p></li>
<li><p>The code itself should follow Evennia’s [Code style guidelines][codestyle].</p></li>
<li><p>The code must be well documented as described in our <aclass="reference external"href="https://github.com/evennia/evennia/blob/master/CODING_STYLE.md#doc-strings">documentation style
guide</a>. Expect that your
code will be read and should be possible to understand by others. Include comments as well as a
header in all modules. If a single file, the header should include info about how to include the
contrib in a game (installation instructions). If stored in a subdirectory, this info should go into
a new <codeclass="docutils literal notranslate"><spanclass="pre">README.md</span></code> file within that directory.</p></li>
<li><p>Within reason, your contribution should be designed as genre-agnostic as possible. Limit the
amount of game-style-specific code. Assume your code will be applied to a very different game than
you had in mind when creating it.</p></li>
<li><p>To make the licensing situation clear we assume all contributions are released with the same
<aclass="reference internal"href="Licensing.html"><spanclass="doc">license as Evennia</span></a>. If this is not possible for some reason, talk to us and we’ll
<li><p>Your contribution must be covered by <aclass="reference internal"href="Coding/Unit-Testing.html"><spanclass="doc">unit tests</span></a>. Having unit tests will both help
make your code more stable and make sure small changes does not break it without it being noticed,
it will also help us test its functionality and merge it quicker. If your contribution is a single
module, you can add your unit tests to <codeclass="docutils literal notranslate"><spanclass="pre">evennia/contribs/tests.py</span></code>. If your contribution is bigger
and in its own sub-directory you could just put the tests in your own <codeclass="docutils literal notranslate"><spanclass="pre">tests.py</span></code> file (Evennia will
find it automatically).</p></li>
<li><p>Merging of your code into Evennia is not guaranteed. Be ready to receive feedback and to be asked
to make corrections or fix bugs. Furthermore, merging a contrib means the Evennia project takes on
the responsibility of maintaining and supporting it. For various reasons this may be deemed to be
beyond our manpower. However, if your code were to <em>not</em> be accepted for merger for some reason, we
will instead add a link to your online repository so people can still find and use your work if they
