- Contribution guidelines
We are so excited that you want to contribute to the Mentored Sprints Community website repository ✨. And we are committed to ensuring that every user and contributor feels welcome and included in this community.
All kinds 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.
Mentored Sprints is a community-led and collaboratively developed project. We, therefore, require that all our members and their contributions adhere to our Code of Conduct (CoC). Please familiarize yourself with our CoC that lists the expected behaviours. We have also provided details for CoC reporting and enforcement, which can be read in our Community Handbook.
The Mentored Sprints project aims to be inclusive to people from all walks of life and to all backgrounds and communities. These intentions must be reflected in the contributions that we make to the project.
In addition to the CoC, we encourage intentional, inclusive actions from contributors to The Mentored Sprints project Here are a few examples of such actions:
- use respectful, gender-neutral and inclusive language (learn more about inclusive writing, resource by the University of Leicester).
- aim to include perspectives of folks from all walks of life
- make sure that your content is accessible (we recommend running pa11y locally before committing your changes). If adding figures ensure your colour palette is colour-blind friendly. Here's a useful blog post on tips for designing scientific figures for colour blind readers by Luk at Somersault 1824.
There are many ways to get in touch:
- Github issues
- Join a discussion or collaborate on ongoing tasks
- @mentoredsprints on Twitter
- Our mailing list/newsletter
- Email the core team
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! ✨.
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.
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.
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.
These issues contain a task that a member of the team has determined we need additional help with.
Nobody is currently working on these issues so are open for anyone willing to work on them.
-
These issues relate to building and supporting the Mentored Sprints community.
-
These issues relate to coordinatng events.
*  These issues are questions and represent a great place to start.
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.
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.
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.
These issues are asking for enhancements or additions to the documentation.
-
Items to add to the newsletter.
-
Related to how we interact with and support mentees.
-
Related to how we interact with and support mentors.
-
Related to how we interact with and support projects.
-
Related to how we interact with and support organizers.
Either the issue or the PR is blocked due to other actions from the maintainer or tooling related.
This issue or PR is actively being worked on.
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.
These issues or PR are actively being reviewed by someone.
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.
This PR has gone through a review and is prepared to be incorporated into the project.
These PRs are still waiting for someone else to review them.
These PRs are currently reviewed by someone else.
The PR reviewer has asked for changes before being able to incorporate the changes to the project.
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.
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 ready it to be merged into the central 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! 😃 🎉 ✨
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.