Contribution Guidelines

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its causes.

Contribution Process

1. Fork and Clone

Fork: Navigate to the repository on GitHub and click the "Fork" button to create a copy of the repository in your own GitHub account.
Clone: Clone your forked repository to your local machine.

2. Create a Branch

Create a new branch to work on your changes. Use a descriptive name for the branch, such as feature/add-smthg or fix/linting-error:
```
git checkout -b <branch-name>
```

3. Development

Make your changes in the newly created branch.

4. Verify Everything

Before submitting your changes:

Verify that your changes have not introduced any linting errors.
```
npm run markdownlint
```

5. Push Changes

Push your branch to your forked repository:

git push origin <branch-name>

6. Create a Pull Request

Navigate to the original repository on GitHub and click the "Compare & Pull Request" button for your branch.
Provide a clear and detailed description of your changes in the pull request.

7. Code Review

Once your pull request is submitted, it will undergo a review process.
Be open to feedback and make adjustments as needed. Push updates to your branch, and they will automatically appear in the pull request.

8. Merge

After your pull request has been approved and all checks have passed, it will be merged into the main repository.

Once your contribution is merged, it will become part of the project. I appreciate your hard work and contribution to making this tool better. Also, I encourage you to continue participating in the project and joining in discussions and future enhancements.

Commit Message Conventions

This project follows the Conventional Commits message conventions defined by @commitlint/config-conventional, with some specific adjustments to suit our needs. This standardization helps automate the version management and changelog generation.

The commit message rules are defined in the .commitlintrc.cjs file, which you can refer to for detailed guidelines.

Below are the details of the allowed commit types and their corresponding effects on versioning.

Commit Types

Type	Description	Version Impact
`feat`	Adds a new feature or updating Reviewdog and DCLint versions.	Minor
`fix`	Fixes a bug.	Patch
`refactor`	Code changes that neither fix a bug nor add a feature (including formatting).	None
`perf`	Changes that improve performance.	Patch
`test`	Adds or modifies tests.	None
`deps`	Updates dependencies.	Patch / None for dev-dependencies
`docs`	Documentation only changes.	None
`ci`	Changes to CI/CD configurations.	None
`chore`	Other changes that don't modify source or test files.	None
`revert`	Reverts a commit.	Patch
`release`	Release-specific metadata updates. Reserved for CI/CD.	None

Commit Linter

A commit-msg hook is configured to automatically check commit messages with the defined rules.

Additionally, you can manually validate all commits in your branch using the following command:

npm run commitlint

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!