First off, thanks for taking the time to contribute! 🎉 ✨
The following is a set of guidelines for contributing to SOHW. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
This project adheres to a Mozilla Community Guidelines. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].
To contribute for SOHW, you always required a GitHub account. New to GitHub or contributing to open source for the first time? Check this small free course, How to Contribute to an Open Source Project on GitHub. Each series take only 2-3 mins and you will find this useful.
We know even before you start contributing that getting set up, to work on SOHW and finding a bug that's a good fit for your skills, can be a challenge. Go through our repo and the process going on. If you find anything weird, report it to us. We are determined to solve hurdles all around to make you people comfortable.
Bugs are tracked as GitHub issues. We always say it as a friendly suggestions from your side for our improvements. A huge appreciation for you, since you are caring for us. 😍😇
When you create an issue, please provide the following information by filling in the template.
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible. Don't just say what you did, but explain how you did it. For example, if you moved the cursor to the end of a line, explain if you used a mouse or a keyboard.
- Provide specific examples to demonstrate the steps. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets on the issue, use Markdown code blocks.
- Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
- Explain which behavior you expected to see instead and why.
- Include screenshots and animated GIFs which show you following the described steps and clearly demonstrate the problem.
Bugs listed as Assigned are not usually a good place to start, unless you're sure you have something worthy to contribute. Someone else is already working on it! Even with no assignee, it is polite to check if someone has recently commented that they're looking at fixing the issue.
Once you have found something to work on, go ahead and comment! Let the bug submitter, reviewer, and component owner know that you'd like to work on the bug. You might receive some extra information, perhaps also made the assignee.
Fork this repository. This makes your own version of this project you can edit and use. Make your changes! You can do this in the GitHub interface on your own local machine. Once you're happy with your changes.
Once you have made all your changes, tests, and updated the documentation, make a pull request to move everything back into the main branch of the repository. Be sure to reference the original issue in the pull request. Expect some back-and-forth with regards to style and compliance of these rules. If you are contributing for an issue, then please add the issue number in the comment while sending us a pull request.
Submit a pull request. This opens a discussion around your project and lets the project lead know you are proposing changes.
Be sure to add the relevant tests before making the pull request. Docs will be updated automatically when we merge to master, but you should also build the docs yourself and make sure they're readable.
You can find all currently open conversations under the issues tab.
The current list of labels are here and include:
-
These issues are questions and represent a great place to start. Whomever has opened the issue wants to hear from you!
To reply, read the question and then respond in a variety of different ways:
- If you want to just agree with everything you can react to the post with one of 👍 :laugh: ❤️ 🎉
- Alternatively you could write a comment to:
- express your emotions more dramatically (check out this cheat sheet for emojis you might need)
- provide a more nuanced description of your answer (using your words)
- ask for a clarification
- ask a follow up question
-
These issues don't require any coding knowledge.
If you're looking to contribute but aren't very confident in your coding skills these issues are a great place to start.
All issues with the no code label are asking for feedback or suggestions.
-
These issues relate to applications and can include suggestions for future applications or a to do list for ongoing applications.
The label is intentionally broad: applications can be for anything from funding or membership of workshops etc.
People writing applications always appreciate help pulling together information from other sources and helping with the first draft all the way to the final proof read through. If you like explaining projects in a convincing way, this is a great label to check out!
-
These issues contain a task that anyone with any level of experience can help with.
A major goal of the project is to have as many people as possible complete their very first pull request on one of these issues. They will always have explicit information on who to contact to help you through the process.
Remember: There are no stupid questions!
We can not encourage you enough to submit even the tiniest change to the project repository. Let's go from 😕 & 😧 to 😃 & 🎉 together!
-
These issues contain a task that a member of the team has determined we need additional help with.
If you have particular skills then consider reading through these issues as they are a great place to offer your expertise.
If you aren't sure what to offer, you could also recommend issues to your friends/colleagues who may be able to help.
-
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 features (or anything else) to be added to the project.
If you have a good idea and would like to see it implemented in the SOHW project please open a new issue and add in as much detail as possible.
Please try to make sure that your feature is distinct from any others that have already been 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 relate front end development.
From [wikipedia][link_frontenddev_wiki]: front end development, also known as client side development, is the practice of producing HTML, CSS and JavaScript for a website or web application so that a user can see and interact with them directly.
These issues are likely to be asking for help from experts, either in terms of submitting or reviewing code, or simply providing guidance and advice.
-
These issues relate to planning meetings "in real life".
If you have experience coordinating events and want to make sure we don't fall into common pitfalls please check out these issues and share your thoughts.
