# Guidelines for project contributors ## Table of Contents - [Code of Conduct](#code-of-conduct) - [How to Contribute](#how-to-contribute) - [Commit Structure](#commit-structure) - [PRs and Commits](#prs-and-commits) - [Sign your Work](#sign-your-work) - [All that bureaucracy...](#all-that-bureaucracy) - [Software versions](#software-versions) - [License](#license) - [Contact](#contact) - [Responsible disclosure](#responsible-disclosure) - [Use of this CONTRIBUTING.md file](#use-of-this-contributingmd-file) ## 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. ### 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*. ### 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. Also, including ``Signed-off-by [Your Name] `` is a requirement for everyone submitting PRs and commits. Signing off your work is as simple as including the ``--signoff`` git command option. This lets us easily track who did what and provides additional protection for our project. By signing off your work, you agree to the [Developer Certificate of Origin](https://developercertificate.org). ### All that bureaucracy... You might think that these contribution requirements present a high barrier to entry, and you'd be right! Signing your commits with your key as well as signing them off is a no-brainer once everything is configured and automated. You don't need to do this manually every commit! Creating a key is also pretty simple given that you can follow the guides GitHub published. These requirements help fend off spam contributions and keep everyone accountable and on the same page. They're useful for any project, big and small, learning adventure or production software. ## Software versions **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 **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``. ## Use of this CONTRIBUTING.md file This file may be used as a template for any open source projects along with its accompanying files, excluding LICENSE.md, as long as you include this message with due credit. If you do decide to use this file as a template, make sure to edit the necessary bits, such as the contact section, disclosure section, etc, in order to fit your needs.