# Guidelines for project contributors

## Table of Contents
- [Code of Conduct](#code-of-conduct)
- [How to Contribute](#how-to-contribute)
  - [Sign your Work](#sign-your-work)
  - [Commit Structure](#commit-structure)
  - [Pull Request Guidelines](#prs-and-commits)
- [License](#license)
- [Contact](#contact)
- [Responsible disclosure](#responsible-disclosure)

## Code of Conduct

Our contributor code of conduct has been adopted from the Contributor Covenant, version 2.1, available [here](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html).

Any and all contributions will need to abide by our community contribution guidelines. See the [Code of Conduct](code_of_conduct.md) for more information. Please make sure to take these rules into account before making any PRs, code commits, issues or comments.

## How to Contribute

Contributions are welcome. Simply register for a free account at [Webvoke Studio's Gitea instance](https://code.webvokestudio.pt/user/sign_up) to start contributing. To get started quickly, feel free to sign up with your existing GitHub account.

### Sign your work

**ALL** contributions must be signed with your PGP key (which must also be added to your Gitea profile and published to a key server), no matter how small. PRs with unsigned commits will be closed. If you're not sure how to sign your commits, check out GitHub's [GPG guide](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key), [Git configuration](https://docs.github.com/en/authentication/managing-commit-signature-verification/associating-an-email-with-your-gpg-key) guide and [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) guides, respectively.

### Commit Structure

We follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) commit structure; this is both human and machine-friendly, ensuring clean and uniform commit messages across the board.

Here are some examples of what is and isn't acceptable:

**Acceptable:**
 - fix(docs): fix a typo in README.md
 - fix: fix bug with utility function get_line_ip
 - refactor: refactor utility functions for more fluidity

**Unacceptable:**
 - fixed bug in get_line_ip
 - added a new feature X
 - added files by upload

These are just some examples, but you get the gist; follow the imperative structure of Conventional Commits and you'll be OK; once you get used to it, you won't want to go back to your old style!

### PRs and Commits

The main branch is protected; For new features, bug fixes, or improvements, fork the repository:
 - Create a new branch from main ``feat/[feature-name]`` for new features;
 - Create a new branch from main ``bugfix/[fix-name]`` and make your bug fix;
 - Create a new branch from main ``improvement/[name]`` for everything else.

You should then be able to create a PR to merge your branch into main. Make sure the PR is as descriptive as possible. *DON'T FORGET TO SIGN YOUR WORK*.

**Ruby version**

We're using Ruby 3.2.3 for this project.


## License

This project is licensed under the GNU Affero General Public License, Version 3. All new contributions will fall under this license; by uploading your code, you agree to license and keep it and under AGPLv3. See [LICENSE.md](LICENSE.md) for more information.

## Contact

**Project maintainer**
 - Miguel Nogueira <me@nogueira.codes>

**Other Contributors**

Please add your name here; Email is not necessary unless you've already configured your PGP key.

## Responsible disclosure
 
While this is mostly a hobby/learning project written during a Programming class, it's still important to fix any possible vulnerabilities in the code; Especially because beginner developers might expose themselves to external risk and threats if they deploy this code to production.

As such, if you find a vulnerability, please send an email to the project maintainer and make sure that it's signed with your key and encrypted with PGP Key ID ``E7EC6E9F446392D20AC7B6DF66F99BACACB8DC54``.