We're looking for people interested in contributing to the project.
Currently the technologies we use include:
- C#
- Python
- Electron
- Node.js
- Angular
- Socket.io
For more detailed project specifications head over to https://leaguesandbox.github.io/
If you're interested in contributing, come find us from Discord and let us know.
All contributors must sign a CLA (Contributor License Agreement) before pull requests can be merged. This will be handled by a bot on the pull request, and the goal is to to ensure the changes being properly transformed to AGPL-3.0 which the project is licensed under.
All commits should refer to issues. This is simply so that we can better track what is being worked on or what should be worked on.
Issue Reference -- Title of the commit
Description of the commit
Issue reference
For example:
Resolve #123 -- Implement a foobar
Implement foo to the bar module
Refs #123
You can also use Progress
in place of Resolve
, in case the issue was not resolved yet.
THIS GUIDE CONCERNS COMMIT MESSAGES, AND NOT PULL REQUEST MESSAGES
- Line length should be 120 characters maximum whenever possible (use Editor Guidelines plugin for a ruler)
- Pull requests must be approved before they can be merged
- Pull requests should not be merged before the build has passed
- If the build fails, ping the pull request creator and tell him to fix it
- Files and folders in
PascalCase
- JSON dictionary keys in
PascalCase
- Keep the code as simple and clear to read as possible
- Each separate feature should be developed in their own branch
- Commits should be in logical small pieces
- Pull requests should be kept as small as possible, generally one feature per pull requests
- Instead of submitting one huge pull request with 3 features, submit each feature individually
- Function names in
PascalCase
- Constants in
ALL_CAPS
- Private variables in
_camelCaseWithUnderscore
- Public properties as getters / setters in
PascalCase
- All
public
variable access should happen through getters / setters #region
s shouldn't be used, instead split code into classes/files when needed- Dictionaries preferred over
switch
es and longif/else
statements - Boolean variable names should be prefixed with a question (is/can/should)
- All
if/else/while/for/foreach/try/catch/finally/lock
clauses should be wrapped inside brackets ({}
), even if they are only one line. - Conditional operator should be avoided.
condition ? option1 : option2
- This is fine to use in some niche cases where you can't avoid using it
- Interpolated strings with embedded logic should not be used
Using git shell is strongly encouraged
- Pull latest version of indev
git fetch -p
git pull origin indev
- Checkout to a new branch
git checkout -b <branch_name>
- Make changes, do commits
git status
- List of changed filesgit add <filename>
- Stage file for commitgit add -u
- Stage all updated files for commitgit add -A
- Stage all unstaged files for commitgit commit -m "<commit message>"
- Create commit
- Push to github
git push origin <branch_name>
- Create pull request
- Checkout back to indev
git checkout indev
- Repeat
Issues uses tag system that make them easier to identify. Tags are grouped into several groups named with first letter of the group name followed by a short-hand descriptive word or phrase. Tags in group are in same color. Every issue should have relevant tags.
To-what part of the code is relevant?
Tag label | Description |
---|---|
A-ai | Content releated to Artificial Intelligence |
A-collision | Content releated to collision |
A-connection | Content releated to connection |
A-content-pipeline | Content related to loading |
A-networking | Content related to networking |
A-packets | Content related to packets |
A-script-engine | Content related to script engine (items, champion's scripts) |
A-security | Content related to security |
A-tools | Content related to tools |
A-vision | Content related to vision |
Issue is blocking on something before it can be resolved
Tag label | Description |
---|---|
B-reproduce | Blocked on a need to reproduce problem locally |
B-needs-verification | Blocked due to missing verification |
The expected complexity of fixing the issue.
Tag label | Description |
---|---|
E-easy | Can be easily resolved |
E-good-first-issue | Issue which will help you get into the project |
E-help-wanted | Assignee/Issue creator requests help? |
The effect of the issue remaining unresolved.
Tag label | Description |
---|---|
I-cleanup | No impact; the issue is one of maintainability or tidiness. |
I-crash | Application crash |
I-enhancement | No impact; the issue is a missing or proposed feature |
I-performance | Unnecessary memory usage/Performance degradation |
I-wrong | An incorrect behaviour is observed (bug) |
Priority of the issues.
Tag label | Description |
---|---|
P-high | High priority |
hacktoberfest | Hacktoberfest, no prefix cause it's a special github label iirc |
Status of the issues.
Tag label | Description |
---|---|
S-clarifying | This issue needs clarification |
S-has-open-pr | There is a PR open that resolves the issue |
S-testing-needed | Needs testing |
S-unverified | This issue needs verification |
S-verified | This issue has been verified |
S-wont-fix | The issue will not be fixed |
invalid | Used for mark spam hacktoberfest PR's as invalid (they will not count) |