Wanna help out? Great! Here’s how.
Spreading the word¶
Help with Documentation¶
Contributing through a forked repository¶
developbranches directly. It will make your life a lot easier.
masterbranch of Evennia, while new features/contribs should go into
developbranch. If you are unsure, just pick one and we’ll figure it out.
Contributing with Patches¶
Contributing with Contribs¶
contrib/directory. Such contributions should always happen via a
- If you are unsure if your idea/code is suitable as a contrib, ask the devs before putting any work into it. 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.
- If your code is intended primarily as an example or shows a
concept/principle rather than a working system, it is probably not
contrib/. You are instead welcome to use it as part of a `new tutorial`_!
- 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).
- 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.
- The code itself should follow Evennia’s `Code style guidelines`_.
- The code must be well documented as described in our `documentation
style guide`_. 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
README.mdfile within that directory.
- 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.
- To make the licensing situation clear we assume all contributions are released with the same `license as Evennia`_. If this is not possible for some reason, talk to us and we’ll handle it on a case-by-case basis.
- Your contribution must be covered by `unit tests`_. 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
evennia/contribs/tests.py. If your contribution is bigger and in its own sub-directory you could just put the tests in your own
tests.pyfile (Evennia will find it automatically).
- 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 not 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 want.
Request: https://github.com/evennia/evennia/pulls .. _patch: https://secure.wikimedia.org/wikipedia/en/wiki/Patch_%28computing%29 .. _Pastebin: http://pastebin.com/ .. _new tutorial: https://github.com/evennia/evennia/wiki/Tutorials .. _Code style guidelines: https://github.com/evennia/evennia/blob/master/CODING_STYLE.md .. _documentation style guide: https://github.com/evennia/evennia/blob/master/CODING_STYLE.md#doc-strings .. _license as Evennia: Licensing.html .. _unit tests: Unit-Testing.html