Skip to content

Latest commit

 

History

History
174 lines (98 loc) · 10.2 KB

CONTRIBUTING.md

File metadata and controls

174 lines (98 loc) · 10.2 KB

Contribution guidelines

🔖 Table of contents

🌈 Welcome to the Mentored Sprints Community Handbook repository 🌈.

We are so excited that you want to contribute to The Community handbook ✨. And we are committed to ensuring that every user and contributor feels welcome and included in this community.

All kind of contributions are welcome and are accepted through GitHub issues and pull requests (PR). Please read these guidelines to make sure we can integrate your contributions easily into the project.

🙌 Contributing through GitHub

To get started, you will need a GitHub account and sign-in. Here are some instructions to get you all set up.

You'll use Markdown to chat in issues and pull requests on GitHub. You can think of Markdown as a few little symbols around your text that will allow GitHub to render the text with formatting. For example, you could write words as bold (bold), or in italics (italics), or as a link (link) to another webpage.

GitHub has a helpful page on getting started with writing and formatting Markdown on GitHub.

Also, when writing in Markdown, please start each new sentence on a new line. While this formats in the same way as if the new line wasn't included, it makes the diffs produced during the pull request review easier to read! ✨.

📝 Share your thoughts, bugs, requests and the such

Issues are individual pieces of work that need to be completed to move the project forward. A general guideline: if you find yourself tempted to write a great big issue that is difficult to describe as one unit of work, please consider splitting it into two or more issues.

Issues are assigned labels which explain how they relate to the overall project's goals and immediate next steps.

🔖 Issue labels

The current list of labels can be found here. You will notice that they are grouped based on their purpose, this is aimed to make it easier for you and the reviewers.

Per availability

  • Good First Issue These issues contain a task that anyone with any level of experience can help. These issues are particularly appropriate if it is your first contribution to the project or to GitHub overall.

  • mentored sprints These are actionable issues that can be completed in a contribution sprints.


  • Help Wanted 🙌🏼 These issues contain a task that a member of the team has determined we need additional help with.

  • Up for grabs 🙌🏼 Nobody is currently working on these issues so are open for anyone willing to work on them.

Issue type

  • Type: Question These issues are questions and represent a great place to start.

  • Type: No Code ⚡️ These issues don't require any coding knowledge.

If you're looking to contribute but aren't ready to write some code yet this is an excellent place to start.

All issues with the Type: No Code ⚡️ label are asking for feedback or suggestions.


  • Type: Bug🐛 These issues point to problems in the project.

If you find a bug, please give as much detail as possible in your issue.

If you experience the same bug as one already listed, please add any additional information that you have as a comment.


  • Type: Enhancement ✨ These issues are asking for enhancements to be added to the project.

Please try to make sure that your enhancement is distinct from any others previously requested or implemented. If you find one that's similar, but there are subtle differences, please reference the other request in your issue.


  • Type: Documentation 📖 These issues are asking for enhancements or additions to the documentation.

Issue or PR status

  • Status: Blocked Either the issue or the PR is blocked due to other actions from the maintainer or tooling related.

  • Status: In progress This issue or PR is actively being worked on.

  • Status: Review needed If you are working on a PR and need an extra pair of eyes, please add this label. This also applies to completed PR that are ready to be reviewed and merged.

  • Status: In review These issues or PR are actively being reviewed by someone.

PR workflow status

  • PR: Draft We encourage that as soon as you start working on an issue, you create a PR as early as possible. If this is not yet ready to be reviewed or merged, mark it as a draft.

  • PR: MRG ready This PR has gone through a review and is prepared to be incorporated into the project.

  • PR:  Awaiting review These PRs are still waiting for someone else to review them.

  • PR: In review These PRs are being currently reviewed by someone else.

  • PR: Changes requested The PR reviewer has asked for changes before being able to incorporate the changes to the project.

🎬 Make a change through a pull request (PR)

The following steps are a guide to help you contribute in a way that will be easy for everyone to review and accept with ease.

1. Comment on an existing issue or open a new issue referencing your addition to the project

This blog is an excellent explanation of why putting this work in upfront is so useful to everyone involved.

2. Fork the project's repository to your profile

This will be your unique copy of the project. You can now do whatever you want with this copy of the project. You won't mess up anyone else's work, so you're super safe.

3. Make the changes you've discussed

Try to keep the changes focused. If you submit a large amount of work all in one go, it will be much more work for whoever is reviewing your pull request.

4. Submit a Pull Request

We encourage you to open a pull request as early in your contributing process as possible. This allows everyone to see what is currently being worked on. It also provides you, the contributor, feedback in real-time from both the community and the continuous integration as you make commits (which will help prevent stuff from breaking). Make sure to add the relevant labels if you need someone to have a look at your PR.

When you are ready to submit a pull request, you will automatically see the Pull Request Template contents in the pull request body. It asks you to:

  • Describe the problem you're trying to fix in the pull request, reference any related issue and use fixes/close to automatically close them, if pertinent.
  • List of changes proposed in the pull request.
  • Describe what the reviewer should concentrate their feedback on.

If you have opened the pull request early and know that its contents are not ready for review or to be merged, add "[WIP]" at the start of the pull request title, which stands for "Work in Progress". When you are happy with it and are happy for it to be merged into the main repository, change the "[WIP]" in the title of the pull request to "[Ready for review]". Also, make sure to add the labels PR: Draft or PR: MRG ready accordingly.

Success!! 🎉 Well done! 😃 🎉 ✨

Thank you!

You are awesome. 💜 ✨ ⭐

And if you've found typos in this (or any other) page, you could consider submitting your very first pull request to fix them.