Skip to content

Latest commit

 

History

History
93 lines (65 loc) · 3.7 KB

CONTRIBUTING.md

File metadata and controls

93 lines (65 loc) · 3.7 KB
Raw

Contributing

Thanks for your time and interest for contributing to the IVPN Web project!
As a contributor, here are the guidelines we would like you to follow:

Contributing Code

  • By contributing to this project you are agreeing to the terms stated in the Contributor License Agreement.
  • By contributing to this project, you share your code under the GPLv3 license, as specified in the License file.
  • Don't forget to add yourself to the Authors file.

Creating an Issue

  • If you want to report a security problem DO NOT CREATE AN ISSUE, please read our Security Policy on how to submit a security vulnerability.
  • When creating a new issue, choose a "Bug report" or "Feature request" template and fill the required information.
  • Please describe the steps necessary to reproduce the issue you are running into.

Pull Requests

Good pull requests - patches, improvements, new features - are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.

Please ask first before embarking on any significant pull request (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the developers might not want to merge into the project.

Follow these steps when you want to submit a pull request:

  1. Go over installation guides in the README
  2. Follow our Git Workflow
  3. Follow instructions in the PR Template
  4. Update the README file with details of changes if applicable

Git Workflow

This project is using Git Feature Branch Workflow.

Branch naming guidelines

Naming for branches is made with following structure:

<type>/<short-summary-or-description>

Where can be epic, feature, task, bugfix, hotfix or release.

Branches

main - The production branch. Clone or fork this repository for the latest copy.
<feature branch> - The feature or fix branch. Pull requests should be made from this branch into main brach.

Commit Message Guidelines

We have very precise rules over how our git commit messages should be formatted. This leads to readable messages that are easy to follow when looking through the project history.

Commit message format

We follow the Conventional Commits specification. A commit message consists of a header, body and footer. The header has a type, scope and subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.

Type

Must be one of the following:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests
  • build: Changes that affect the build system
  • ci: Changes to our CI configuration files and scripts
  • vendor: Bumping a dependency like libchromiumcontent or node
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation