|
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899 |
- # Contributing Guide
-
- 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](https://discord.gg/gnsn7ZP).
-
- ## Issues
-
- ### Creating Issues
-
- * Isleward uses the integrated [Issue Tracker](https://gitlab.com/Isleward/isleward/issues) on GitLab.
- * Issues are used to track work to be done (this includes bug fixes).
- * Before making a new issue, make sure the same issue is not already listed in the issue tracker, either opened or already closed.
- * In case it is listed and you have some more info, for example on how to reproduce a bug, post a comment in the original issue.
- * If the issue is of a more sensitive nature (a serious game breaking exploit for example), please report the issue as [confidential](#confidential-issues).
-
- ### Issue Labels
-
- Labels can only be assigned by people with Reporter and higher permissions in the project (see [Members](https://gitlab.com/Isleward/isleward/project_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:
-
- * ~Balance
- * ~Bug
- * ~Content
- * ~Draft
- * ~Feature
- * ~Modding
- * ~Polish
- * ~Refactor
- * ~DevOps
-
- ### Issue Weights
-
- * In addition to labels, issues tagged with the ~Bug label are also assigned Weights.
- * Bugs are weighed by severity, with 1 being trivial and 5 being severe.
- * Weights can assigned by people with Reporter or higher privileges, but this should only be done by @rstan122 unless instructed otherwise.
-
- ### Confidential Issues
-
- * Confidential issues are issues that are visible only to people with Reporter or higher access rights.
- * Therefore they are very useful for reporting issues that are very sensitive and that not every user should know about.
- * To create a confidential issue, simply check the `This issue is confidential and should only be visible to team members with at least Reporter access.` checkbox when creating a new issue.
-
- ### Becoming a Reporter
-
- For more information about becoming a reporter, contact Waf on [Isleward's Discord](https://discord.gg/gnsn7ZP).
-
- ## Project Workflow
-
- ### Branching Structure
-
- The project is using the following branching structure
-
- * `master`
- * `release`
- * release tags (e.g. `0.3.1`)
- * feature branches (e.g. `990-contributing-rewrite`)
-
- **master** is the "nightly" branch, so to speak. All feature branches should be branched from and merged into `master`.
-
- **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` in `990-contribuing-rewrite`), be all lowercase with hyphens between words.
-
- ### Using SSH keys
-
- While not necessary, it is recommended to use SSH keys with git. Please follow [this page](https://gitlab.com/help/ssh/README.md) to learn how to set up and use SSH keys.
-
- ### Forking and Syncing
-
- 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](https://docs.gitlab.com/ce/workflow/forking_workflow.html).
-
- In case your work on the contribution is taking longer, your branch may become out of date with the parent repository. [This article](https://help.github.com/articles/syncing-a-fork/) from GitHub will help you sync your fork with the upstream (parent) repository.
-
- ### Code Style and Linting
-
- 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](https://gitlab.com/Isleward/isleward/wikis/JS-Style-Guide).
-
- ### Merge Requests
-
- 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.
-
- ### Running Isleward
-
- * [Windows](https://gitlab.com/Isleward/isleward/wikis/installation-and-usage-(windows))
- * [Linux](https://gitlab.com/Isleward/isleward/wikis/installation-and-usage-(linux))
- * [MacOS](https://gitlab.com/Isleward/isleward/wikis/installation-and-usage-(macos))
|