diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..bbc6136 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,198 @@ +# Contributing to semantic-release + +As a contributor, here are the guidelines we would like you to follow: + +- [How can I contribute?](#how-can-i-contribute) +- [Using the issue tracker](#using-the-issue-tracker) +- [Submitting a Pull Request](#submitting-a-pull-request) +- [Coding rules](#coding-rules) +- [Git Commit Type](#git-commit-type) +- [Working with the code](#working-with-the-code) + +## How can I contribute? + +### Give feedback on issues + +Some issues are created without information requested in the [Bug report guideline](#bug-report). +Help make them easier to resolve by adding any relevant information. + +Issues with the [discussion label](https://github.com/Blvckleg/BingusBoingus/labels/discussion) are meant to discuss the implementation of new features. + +### Fix bugs and implement features + +Confirmed bugs and ready-to-implement features are marked with the [help wanted label](https://github.com/Blvckleg/BingusBoingus/labels/help%20wanted) or the [bug label](https://github.com/Blvckleg/BingusBoingus/labels/bug). + +## Using the issue tracker + +The issue tracker is the channel for [bug reports](#bug-report), [features requests](#feature-request) and [submitting pull requests](#submitting-a-pull-request) only. + +### Bug report + +A good bug report shouldn't leave others needing to chase you for more information. +Please try to be as detailed as possible in your report and fill the information requested in the [bug report template](https://github.com/Blvckleg/BingusBoingus/blob/master/.github/ISSUE_TEMPLATE/bug_report.md). + +### Feature request + +Please provide as much detail and context as possible and fill the information requested in the [feature request template](https://github.com/Blvckleg/BingusBoingus/blob/master/.github/ISSUE_TEMPLATE/feature_request.md). + +## Submitting a Pull Request + +Good pull requests, whether patches, improvements, or new features, are a fantastic help. +They should remain focused in scope and avoid containing unrelated commits. + +Here is a summary of the steps to follow: + +1. Create issue + +2. Create issue branch from main +3. Make your code changes, following the [Coding rules](#coding-rules) +4. Push your topic branch + +```bash +git push origin +``` + +5. [Open a Pull Request](https://help.github.com/articles/creating-a-pull-request/#creating-the-pull-request) with a clear title and description. + +**Tips**: + +- For ambitious tasks, open a Pull Request as soon as possible with the `[WIP]` prefix in the title, in order to get feedback and help from the community. + + +## Coding rules + +### Source code + +To ensure consistency and quality throughout the source code, all code modifications must have: + +- No [linting](#lint) errors +- A [test](#tests) for every possible case introduced by your code change +- [Valid commit message(s)](#commit-message-guidelines) +- Documentation for new features +- Updated documentation for modified features + +### Documentation + +To ensure consistency and quality, all documentation modifications must: + +- Refer to brand in [bold](https://help.github.com/articles/basic-writing-and-formatting-syntax/#styling-text) with proper capitalization, i.e. **GitHub**, **Nestjs**, **npm** +- Prefer [tables](https://help.github.com/articles/organizing-information-with-tables) over [lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#lists) when listing key values, i.e. List of options with their description +- Use [links](https://help.github.com/articles/basic-writing-and-formatting-syntax/#links) when you are referring to: +- Use the [single backtick `code` quoting](https://help.github.com/articles/basic-writing-and-formatting-syntax/#quoting-code) for: + - programming language keywords, i.e. `function`, `async`, `String` +- Use the [triple backtick `code` formatting](https://help.github.com/articles/creating-and-highlighting-code-blocks) for: + - code examples + - configuration examples + - sequence of command lines + +### Commit message guidelines + +#### Atomic commits + +If possible, make [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit), which means: + +- a commit should contain exactly one self-contained functional change +- a functional change should be contained in exactly one commit +- a commit should not create an inconsistent state (such as test errors, linting errors, partial fix, feature with documentation etc...) + +A complex feature can be broken down into multiple commits as long as each one maintains a consistent state and consists of a self-contained change. + +#### Commit message format + +Each commit message consists of a **header**, a **body** and a **footer**. +The header has a special format that includes a **type**, a **scope** and a **subject**: + +```commit +(): + + + +