Skip to content

Latest commit

 

History

History
36 lines (25 loc) · 2.71 KB

CONTRIBUTING.md

File metadata and controls

36 lines (25 loc) · 2.71 KB

Contributing to MONOREPO

What contributing means 🤝

Contributions to a project can take many forms, but ultimately they are all ways to make said project better. We use GitHub Issues to organize how we chunk out work and assign tasks.

Project tasks ✅

Tasks are created at the beginning and throughout a project's development, and they come directly from the project's specifications. Each task represents an amount of work achievable by one person and ultimately add up toward an ultimate goal.

Bugs 🐞

As much as we love our work, we know it isn't always perfect. Sometimes unexpected behaviour comes up and that's unavoidable. These are bugs in our code, and they can be reported through GitHub Issues as well! There will be a template that asks for additional details such as screenshots and how to reproduce the bug.

Improvements/suggestions ✨

Last but not least, code improvements/suggestions are very welcome! With these it's important to clearly define the suggestion and the amount of work/steps required to implement it.

As an open-source project, members outside of the team are welcome to contribute! That being said, most of these contributions will lean toward bug reports and improvements/suggestions.

Writing/reviewing pull requests 📥

To make changes to the main branch in an organized and clean manner, it's good practice to request such changes through a pull request (PR).

If there's anything in the review process that you want to improve, please let us know!

Writing pull requests 📝

When you create a pull request there will be a template that you can follow - this is a guide for what content you should include. Pull requests provide context and reasoning to changes, and your main goal is to describe what your code can't by itself. Things to keep in mind:

  • keep writing and explanations concise
  • explain concepts/terminology that might not be familiar to reviewers
  • as an author, be receptive to comments and feedback

Reviewing pull requests 👀

Pull requests require an approving review from a contributor with write access before they can pushed up to the main branch. If you're unsure of who you should ask for a review you can check the CODEOWNERSfile.

Reviewing is also a great way to learn about the codebase, learn what others are working on, and improve your own coding practices!

As a reviewer:

  • clearly outline your changes/suggestions
  • review and follow up on subsequent changes in a timely manner to keep pull requests from going stale