Skip to content

A guide on the Basics @ Development Guide:

To get started you must have a GitLab account (Guide). Once you have a GitLab Account head over to the repository (linked in the footer).

Creating a Issue:

If you have a bug report, feature request or etc. Please open an issue. Use the main template. In the summary section note down your bug report, feature request or etc. For bug reports please have evidence uploaded. Any issue that proposes changes to existing code must outline the benefits and the drawbacks of such change(s).

If you wish to lead the issue you can. If you do not want to, do not assign yourself.

Please select labels that you believe best fit the issue. They are pretty easy to understand.

You do not have to set a milestone for the issue. But bug fixes should release after a maximum of 1 release.

If your issue is proposing a refactor please follow the guidelines below:

  1. Improve maintainability.
  2. Avoid Conflicts.
  3. Describe the refactoring. Why is it needed? How would it solve the issue?
  4. Showcase the benefits and negatives of the refactoring.
  5. Only edit what's needed.
  6. MRs (Merge Requests, including the Issue if one was opened) should not be open for longer than 14 days.

Refactoring proposals must be for the following reasons:

  1. Improves performance, security, efficiency, maintainability.
  2. Allows new features to be added.
  3. Removes certain barriers / limitations.

Quote

"A software development process that improves existing code without altering its external behavior"

Merge Requests:

Upon creating an issue. To make any changes you must create a merge request (an "mr" for short). With that merge request's branch push and commit all the changes needed.

Note

When creating a merge request you do not have to edit the title, description, labels (inherited from the issue) or milestone. If you wish to be the assignee you can assign yourself that. However you can not assign yourself the reviewer role.

  • Your target branch should always be the main branch.
    • The main branch is protected.
  • Always make your merge request can pass CI/CD.

Tip

We recommend you keep your merge request's source branch up-to-date. To do this enter the command below in your IDE's Git Terminal:

Bash
1
git pull origin main

Git Commit Styling:

Good examples:

  1. fix: {bug}
  2. feat: {new feature name}
  3. imprv: {improvement short description}
  4. qol: {qol short description}
  5. pckgs: {updates to dependencies}

As long as its appropriate, we won't judge.

Tip

We recommend following the Conventional Commits style guide.

Note

You can also use emojis in your commits. Follow the gitmoji guide.

Code Style and Format:

Ensure your code is following all the rules set out in ruff.toml, .yamlint.yml and .editorconfig.

Tip

Download extensions. E.g. the Ruff & EditorConfig extensions. Recommended vs-code extensions can be found in the .vscode directory.