Skip to content

👀 Contributing guidelines

  1. Join our team
  2. Environment setup
  3. Conventional commits
  4. Pull requests guidelines
  5. Versioning

Join our team

👋 Welcome to REDGNUS!

All contributions from the community, feedback, innovative ideas, bug reports, pull requests, and doc translations are most welcome.

It is a pleasure for our team to have you here. Any help is highly appreciated. Here are some brief hints on where to start, and how.

This project aims to be a comfortable and welcoming space for teams and for individuals who constantly improve it through collaboration. Every contributor will need to adhere to our Community Guidelines.

Did you face abusive behavior in this project? Sorry!!! Refer to the Enforcement section (Policy Violation) of the Community Guidelines (Code of Conduct) for information on how to raise a complaint (PM redtux).

Environment setup

The project maintainers kindly ask all contributors to stick to the project layout, and to the directory structure – for future and for existing projects inside the redgnus namespace. Here is a list of linters that our team uses before every commit. Hope you'll enjoy it!

To start a development environment, run the following commands:

python3 -m venv .venv
source .venv/bin/activate
pip3 install -r requirements.txt

To manually install all linting tools, run the following commands:

pip3 install --user --upgrade pip
pip3 install --user dotenv-linter
pip3 install --user editorconfig-checker
pip3 install --user hadolintw
pip3 install --user mkdocs-material
pip3 install --user mkdocs-with-pdf
pip3 install --user shellcheck-py
pip3 install --user yamllint
pip3 install --user wheel
pip3 install --user git+git://github.com/AleksaC/hadolint-py.git@v2.8.0
npm install -g markdownlint-cli

Conventional commits

All REDGNUS projects follow the Conventional Commits specification. Therefore, all commit messages must follow the Angular style standard, as described here.

<type>[(scope)]: Subject
[Body]

Scope and body are optional. Type can be:

  • build: About packaging and building wheels
  • chore: About packaging or files management
  • ci: About Continuous Integration pipelines
  • docs: About documentation & DEV guidelines
  • feat: Introducing a feature or enhancement
  • fix: a. Fixing a bug – b. Closing an issue
  • perf: About a. performance – b. monitoring
  • refactor: Change that is no feature or fix
  • style: Changes in code style / code format
  • tests: About QA policy or test integration

Subject (and body) must be valid Markdown. If you write a body, add references to issues or tracking numbers at the end:

Body.
See #10, #11
Close #15

Pull requests guidelines

Link to any related issue in the Pull Request message.

During review, our team recommends using fixup:

# SHA is the SHA of the commit you want to fix
git commit --fixup=SHA

On approval of all changes after a review, you can squash your commits:

git rebase -i --autosquash main

Finally, push your changes to the remote origin repository:

git push

Versioning