Skip to content

Latest commit

 

History

History
35 lines (22 loc) · 3.18 KB

CONTRIBUTING.md

File metadata and controls

35 lines (22 loc) · 3.18 KB
Raw

Contribution rules

About Hacktoberfest 2020

We are happy to participate in Hacktoberfest 2020 and welcome everyone to contribute for a better StorefrontUI 😃.

However, there are several general guidelines, FQAs and rules we would like you to note before starting:

What kind of issues should I start?

Any of our Github issues, which have no assignee. In case there is someone assigned to it and there has been a while since their last update, feel free to ping any of our core maintainers by leave a comment inside the ticket, or in our Discord channel

Also, we label some issues with label hackotoberfest for easy and smooth start, you can refer to the relevant list of issues here

How to contribute

  1. Read component composition rules and how to work with our Figma designs.
  2. Pick an issue and read the guidelines. Write in the issue comment that you want to pick it if you can't assign yourself. Please stay assigned to one issue at a time to not block others
  3. Propose a Pull Request to develop branch containing issue number and component name.
  4. Add label review required so that our maintainers will know we can start reviewing it.
  5. Wait for review and adjust your PR according to it. Please allow minimum 24 hours for someone to start reviewing. Rushing the maintainers is not accepted.
  6. Congrats 🎉! Your PR should now be merged in!

If you can't handle some parts of the issue feel free to ask in the comment. It's absolutely OK if you can only handle styling/tests/whatever.

Rules

  1. No spam allowed. Such activities will be labeled as invalid and you will be blocked from contributing.
  2. Spam also includes unwanted fixes such as removing commas, changing texts, adding comments, removing codes where we do not ask for. If you see something needs attention on docs and not reported, please raise the question the #docs channel of our Discord Server, and/or open a Github issue before making a PR.
  3. Do not use asap word (as soon as possible) in communicating about PR review. Unless it's a hot fix, your fixes will only be available when we release a new version, and that won't happen the same day of your PR. Also, it makes maintainers and code reviewers uncomfortable. There is a buffer of minimum 24 hours before a maintainer start reviewing your code. Please be patient 😉.
  4. Do not ping any maintainer especially during weekends. Everyone needs to have a life and family time 😄.
  5. If you know it's a holiday for a specific maintainer, please do not ping him/her directly on that day regardless. It's called consideration.

That's all. Happy coding and we hope you have a good time contributing!