CONTRIBUTING.md

Contributing Guide 💯

Hello stranger! ✨ Please, read the Code Of Conduct and the full guide at tunnckoCore/contributing! Even if you are an experienced developer or active open source maintainer, it worth look over there.

“Every thought, every word, and every action that adds to the positive is a contribution to peace.
Each and every one of us is capable of making such a contribution.” ~ Aung San Suu Kyi

Firstly, a heartfelt thank you for making time to contribute to this project!

Are you new to Open Source?

If you’re a new open source contributor, the process can be intimidating. What if you don’t know how to code? What if something goes wrong? Don't worry!

You don’t have to contribute code! A common misconception about contributing to open source is that you need to contribute code. In fact, it’s often the other parts of a project that are most neglected or overlooked. You’ll do the project a huge favor by offering to pitch in with these types of contributions!

Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.

• Yes: Step to the full guide if you are new, super curious OR if you're really really new and need more depth.
• No: Then continue reading, if you know for what is all that or you're familiar with @tunnckoCore projects.

Opening an issue

You should usually open an issue in the following situations:

• Report an error you can't solve yourself
• Discuss a high-level topic or idea (ex. community, vision, policies)
• Propose a new feature or other project idea

Tips for communicating on issues:

• If you see an open issue that you want to tackle, comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
• If an issue was opened a while ago, it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
• If you opened an issue, but figured out the answer later on your own, comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
• Please be patient and wait for a response from the maintainer or somebody else. Check out "What to do next?".

Include Any/All Relevant Information in the Issue Description

• Please include as much relevant information as you can, such as versions and operating system.
• A good issue describes the idea in a concise and user-focused way.
• Never leave the issue description blank even when you are in a "rush" - the point of an issue is to communicate.

Why can't the description be empty? You wouldn't send a blank email to hundreds of your friends (unless you wanted to freak them out!), right? Submitting blank issues is doing exactly that! It sends a "I have no idea what I'm doing" message to your peers.

Opening a pull request

If this is your first pull request, check out Make a Pull Request by @kentcdodds.

You should usually open a pull request in the following situations:

• Submit trivial fixes (ex. a typo, broken link, or obvious error)
• Start work on a contribution that was already asked for, or that you've already discussed, in an issue

A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.

Pro Tips to follow

• #1. Check what manager is used:
  • a) if there is yarn.lock run commands with yarn - yarn setup, yarn start lint, yarn run docs and etc.
  • b) if there is hela.config.js file, run hela --help for more info
  • c) otherwise use npm - npm test, npm start lint, npm run docs and etc.
• #2. Don't worry about style - we use Airbnb Style, ESLint and Prettier. Use yarn start lint or hela lint. command.
• #3. Don't change the markdown files, because the READMEs are generated (it isn't hand written) and the API section is from JSDoc code comments. Leave this step to us when, and if, the pull request is merged.
• #4. Don't comment out tests, instead use test.skip or similar. They'll still be shown in the output, but are never run.

How to submit a pull request

Below steps are assumes project is using Yarn, see Protip #1 above.

There are just 8 easy steps you should do. Please, follow them in that exact order.

1. Fork the repository and clone it locally.
2. Create a branch for your edits (e.g. git checkout -b your-branch-name).
3. Install dependencies by running yarn setup or yarn, see Protip #1 above.
4. Test if everything is working before you start doing anything with the yarn test command. If something is wrong, please report it first and don't continue if you can't skip the problem easily.
5. Reference any relevant issues, supporting documentation or information in your PR (ex. "Closes #37.")
6. Test again or add new ones! Run yarn test again to make sure your changes don't break existing tests.
7. Commit your changes by running yarn start commit. It will lead you through what the commit message should look like and will run more tasks to ensure that code style and tests are okey.
8. Wait response! What to do in that time? Check out "What to do next?".

⭐ You did it! ⭐ Congratulations on becoming one of the Open Source contributors!