We appreciate your consideration to make a contribution (no matter how minuscule), any help would be greatly appreciated!
Before contributing in any form, consider reading our documentation and, if that does not scare you away, we invite you to consider joining our Discord or submitting your questions in the discussion area.
This file offers a description of the conventions to follow in order to make a significant contribution to the project in its entirety.
Nevertheless, keep in mind that the most important repositories of this project are currently the ones containing the code and game assets.
Be aware that prompt responses (especially to issues, pull requests and discussions) may not always be feasible due to the limited size of the project team and community.
There are multiple ways to contribute to the project:
- 🚩 opening issues;
- 🛠️ submitting pull requests;
- 🎨 proposing and contributing art assets;
- 🗣️ providing feedback and initiating discussions;
- ✏️ improving documentation;
- 🌱 growing and supporting the community, spreading the word;
- 🧪 testing the project and identifying areas for improvement;
Issues, as the name implies, are primarily used to report and track bugs and organize work. They may occasionally contain feedback, but if you want to ask a few questions, propose an idea or talk about something unrelated to a specific issue, use discussions instead.
In order to successfully open a new issue, you should:
- check if a similar issue already exists or has been resolved. Identical issues may be labeled as
duplicate
and mercilessly closed; - provide as much information as humanly possible about the issue. When reporting a bug, include clear instructions on how to reproduce it;
- feel free to throw in some screenshots or videos, if applicable.
Note: issues are typically open to everyone since we rarely assign them to anyone, so feel free to open a pull request with your suggested solution if you come across something you would like to work on.
Pull requests are submitted when you want to collaborate and propose your finished work to a project, with the aim of having it included.
Even though we always appreciate new and helpful ideas, it is preferable to open a pull request to address an existing issue; if you propose unsolicited changes, keep in mind that there is a chance your pull request could be ignored.
In order to successfully open a pull request, you should:
- check if a similar request already exists; if so, review it to identify any potential problems that have arisen;
- include a description in the pull request that possibly explains what you are doing and why. Help us decipher your genius;
- make sure you are linking the pull request to the issue you are trying to solve;
- attach the files you want to propose or post screenshots or videos, if applicable.
Note: be aware that your work may be altered, either before or after merging, in order to address issues, make improvements or better align with the project.
By contributing, you acknowledge that your code will be subject to the license specified in the repository to which you are committing unless explicitly stated otherwise. For instance, the game's source code is released under the permissive zlib license.
Valhalla's game assets should come with open source-friendly licenses.
You agree to license your contribution under licenses no stricter than CC BY-SA in the event that you wished to contribute to the game's asset repositories, such as the community repository or data submodule (containing the current game assets), unless explicitly stated otherwise.
Note: if you desire to use a different license for your work than the licenses specified in the repository you are contributing to, it is essential to explicitly state your preference.
Before committing, it is a good idea to consider some of the best practices:
- keep the commit message short and sweet (up to 50 characters). If you enjoy the art of writing, try starting a novel instead;
- ensure that your commit messages convey the purpose of the changes made, unlike generic things like "whoops" or "minor edit";
- to undo all the changes made in a commit, simply revert it. Avoid creating additional commits like "undo previous commit!";
- if you need to undo only specific parts of a commit, it is advisable to make a separate commit for that purpose instead of reverting it;
- provide a detailed and clean description of what the commit implies if necessary;
- commits should preferably be written using decent grammar/punctuation. Asking for the world here, but we can always hope for the best;
- make single-purpose commits to make them simpler to understand and revert;
- commit finished work, avoid "part 1" and "part 2" shenanigans;
- use the present tense in the imperative mood for commit messages.