Skip to content

Latest commit

 

History

History
96 lines (69 loc) · 3.95 KB

CONTRIBUTING.md

File metadata and controls

96 lines (69 loc) · 3.95 KB
Raw

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!

And you can contribute to this project in multiple ways:

  1. Share your success stories or confusion moments in Discussions.
  2. Open Issues with bug reports or feature suggestions.
  3. Open Pull Requests (PRs) 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.
  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 and mention your willingness to have it.

I (@chshersh) grant write access to everyone who contributed to tool-sync.