Contribution guide

Most open-source maintainers are volunteers with limited time. These habits make your pull request easier to review, and make you more welcome next time.

Before you start

• Pick an issue that is still open and not assigned to someone. Check for linked pull requests.
• Comment on the issue before you start, so two people don't do the same work.
• Read the project's CONTRIBUTING file, code of conduct and any pull request template. They tell you how the maintainers want changes made.
• If the issue is unclear, ask a question on the issue before writing code.

While you work

• Keep the change to what the issue asks. A small, focused pull request is reviewed faster than a large one. If you spot something else, open a separate issue.
• Follow the project's own code style, naming and commit message format.
• Run the tests before you push. If you fixed a bug, add a test that would have caught it.
• Don't reformat files you aren't changing. It buries the real change.

When you open the pull request

• Describe what you changed and why, in plain words.
• Link the issue with "Fixes #123", using the issue's number.
• Say how you tested it.
• Fill in the project's pull request template, if it has one.

During review

• Be patient. Reviews can take days or weeks.
• Treat comments as being about the code, not about you.
• Reply to each comment, even if it's only "done". Push follow-up commits to the same branch.
• If a maintainer says no, accept it. It is their project.
• If you can't finish, say so on the issue so someone else can pick it up.

If you're stuck

• Say what you tried and what happened, with the exact error message. That earns better answers than "it doesn't work".
• Look at closed pull requests in the same project to see what accepted changes look like.

Contributing to SkillIssues itself

SkillIssues follows the same habits and has a few of its own. See Contribute and CONTRIBUTING.md.

Related

• Getting started
• Finding issues