# Contributing guide

This document describes contributing guidelines for this project.

You're encouraged to read this document before your first contribution. I
appreciate your time spend familiarising yourself with these guidelines.
Following this guide ensures the most positive outcome for contributors and
maintainers! 💖

## How to contribute

Everyone is welcome to contribute as long as they follow our
[rules for polite and respectful communication](https://github.com/chshersh/tool-sync/blob/main/CODE_OF_CONDUCT.md)!

And you can contribute to this project in multiple ways:

1. Share your success stories or confusion moments in
   [Discussions](https://github.com/chshersh/tool-sync/discussions).
2. Open [Issues](https://github.com/chshersh/tool-sync/issues) with bug
   reports or feature suggestions.
3. Open [Pull Requests (PRs)](https://github.com/chshersh/tool-sync/pulls)
   with documentation improvements, changes to the code or even
   implementation of desired changes!

Or anything else! Be creative 🎨

## The golden rule of contribution

When unsure, follow this rule for contributing:

**Better ask than be sorry.**

To give some example:

+ Want to work on an existing issue but not sure if anyone works on it?
  Feel free to ask in comments!
+ Want to work on an existing issue but not sure on which one?
  Feel free to create a discussion and ask!
+ Want to contribute a patch but not sure if it's going to be merged?
  **Create the issue first** if it doesn't exist and just ask!

> You may argue that sometimes it's easier to share your vision with
> exact code changes via a PR. Still, it's better to start a
> Discussion or an Issue first by mentioning that you'll open a PR
> later with your thoughts laid out in code. Or, if you still prefer to open a
> PR first, please, clarify your intentions in the PR description.

Discussing implementation details or various architecture decisions beforehand avoids spending time inefficiently.

Similarly, when you share your intention to work on something in the comment
section under the corresponding issue, it helps to avoid the situation when
multiple people are working on the same problem concurrently.

## Pull Requests requirements

Generally, the process of submitting, reviewing and accepting PRs
should be as lightweight as possible if you've discussed the
implementation beforehand. However, there're still a few requirements:

1. Be polite and respectful in communications. Follow our
   [Code of Conduct](https://github.com/chshersh/tool-sync/blob/main/CODE_OF_CONDUCT.md).
2. The code should be formatted with `rustfmt` using formatting settings from
   this project.
3. Add your changes to the `CHANGELOG.md` file under the `[Unreleased]` section
   in the same format as other changes.

That's all so far!

> ℹ️ **NOTE:** PRs are merged to the `main` branch using the
> "Squash and merge" button. You can produce granular commit history
> to make the review easier or if it's your preferred workflow. But
> all commits will be squashed when merged to `main`.

## Response times

Maintainers of this project strive to respond to you contributions within a
week. Life happens, OSS maintainers also have their lives, so you still might
not get a timely response.

To keep the project moving and avoid having stale PRs and bug reports,
maintainers may decide to close them if they don't hear back from authors in a
week.

> It's okay to say that you're busy now and can only reply/finish properly
> later. But also keep in mind that your contributions might be rejected or
> replaced by someone or something else. Be mindful about other's time and
> capabilities. And be human 💞

## Write access to the repository

If you want to gain write access to the repository, open a
[discussion with the Commit Bits category](https://github.com/chshersh/tool-sync/discussions/categories/commit-bits)
and mention your willingness to have it.

I ([@chshersh](https://github.com/chshersh))
grant write access to everyone who contributed to `tool-sync`.