There are many ways in which you can contribute to the project, be it reporting issues, fixing them, implementing new features or even making art/audio assets.
If anything in this contributing guide is not clear, don’t hesitate to contact Waf or Vildravn on Isleward’s Discord.
Labels can only be assigned by people with Reporter and higher permissions in the project (see Members). People with rights to assign labels should do so regularly to keep the issues organized. The project is using the following, rather self-explanatory, labels:
This issue is confidential and should only be visible to team members with at least Reporter access.checkbox when creating a new issue.
For more information about becoming a reporter, contact Waf on Isleward’s Discord.
The project is using the following branching structure
master is the “nightly” branch, so to speak. All feature branches should be branched from and merged into
release is a single release branch. When a new version is to be released,
master is merged into this branch and a release tag is created.
release tags are pointing at the latest commit in
release at the point of releasing a new version.
feature branches are branches in which the actual development happens. The name of a feature branch should always contain the number of the issue that’s being addressed (e.g. the
990-contribuing-rewrite), and be all lowercase with hyphens between words.
While not necessary, it is recommended to use SSH keys with git. Please follow this page to learn how to set up and use SSH keys.
All contributed work needs to be done in your own fork, in a branch created from the
master branch. To learn more about forking a repository, follow this guide.
In case your work on the contribution is taking longer, your branch may become out of date with the parent repository. This article from GitHub will help you sync your fork with the upstream (parent) repository.
Isleward uses ESLint and has a .eslintrc file with rules set up. When contributing code, please make sure to fix any errors and warnings produced by ESLint as your merge request won’t be accepted otherwise.
Also please make sure to follow the JS Style Guide.
Once you are done working on your contribution, you need to submit a merge request to merge your branch from your fork back into the upstream (parent) repository.
The merge request should have
master as its target branch unless arranged otherwise.
You don’t need to remove the source branch upon accepting the merge request if the merge request is being made from a fork. Squishing commits is usually not recommended as it breaks the ability to rebase nicely in certain cases.
Once your merge request is submitted, GitLab CI will run a few tests on it. Should those tests fail, please address the failures. A Merge Request with passing tests is ready to be merged.