Skip to content

Latest commit

 

History

History
102 lines (68 loc) · 6.4 KB

CONTRIBUTING.md

File metadata and controls

102 lines (68 loc) · 6.4 KB
Raw

Welcome to GithubMaker contributing guide

Thank you for investing your time in contributing to my project! Any contribution you make will be reflected on GithubMaker page ✨.

In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.

New contributor guide

To get an overview of the project, read the README file. Here are some resources to help you get started with open source contributions:

Getting started

Codespace is quite easy to navigate. If you would like to add new filetypes, please test them before you send the pull request.

Issues

Create a new issue

If you spot a problem with the docs, search if an issue already exists. If a related issue doesn't exist, you can open a new issue using a relevant issue form.

Solve an issue

Scan through our existing issues to find one that interests you. You can narrow down the search using labels as filters. Also don't forget to check out closed issues.

Make Changes

Make changes in a codespace

For more information about using a codespace for working on GitHub documentation, see "Working in a codespace."

You can change the functionality of the program by editing any of the files in the codespace. If change any functionality though, please add the changes you have done according to the Git Commit Messages section.

Add new language or edit translation

Please make sure that the translations are accurate.

Commit your update

Commit the changes once you are happy with them. You can follow this simple two steps:

Self-Review

Once your changes are ready, don't forget to self-review to speed up the review process:zap:.

You should always review your own PR first.

For content changes, make sure that you:

  • Confirm that the changes meet the user experience and goals outlined in the content design plan (if there is one).
  • Compare your pull request's source changes to staging to confirm that the output matches the source and that everything is rendering as expected. This helps spot issues like typos, content that doesn't follow the style guide, or content that isn't rendering due to versioning problems. Remember that lists and tables can be tricky.
  • Review the content for technical accuracy.
  • Copy-edit the changes for grammar, spelling.
  • Check new or updated versioning statements to confirm that versioning is correct.
  • If there are any failing checks in your PR, troubleshoot them until they're all passing.

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line
  • Consider starting the commit message with an applicable emoji:
    • 🎨 :art: when improving the format/structure of the code
    • 🐎 :racehorse: when improving performance
    • 🇹🇷 :(flag of the language): when adding or changing translations
    • 📝 :memo: when writing docs
    • 🐧 :penguin: when fixing something on Linux
    • 🍎 :apple: when fixing something on macOS
    • 🏁 :checkered_flag: when fixing something on Windows
    • 🐛 :bug: when fixing a bug
    • 🔥 :fire: when removing code or files
    • ✨ :sparkles: when adding new files
    • 🔧 :wrench: when updating files
    • 🔒 :lock: when dealing with security
    • ⬆️ :arrow_up: when upgrading dependencies
    • ⬇️ :arrow_down: when downgrading dependencies
    • 🎉 :tada: when including new update files

Pull Request

When you're finished with the changes, create a pull request, also known as a PR.

  • Fill the "Ready for review" template so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request.
  • Don't forget to link PR to issue if you are solving one.
  • Enable the checkbox to allow maintainer edits so the branch can be updated for a merge. Once you submit your PR, a Docs team member will review your proposal. We may ask questions or request for additional information.
  • We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
  • As you update your PR and apply changes, mark each conversation as resolved.
  • If you run into any merge issues, checkout this git tutorial to help you resolve merge conflicts and other issues.

Your PR is merged!

Congratulations 🎉🎉 Thanks for your contribution! ✨.

Once your PR is merged, your contributions will be publicly visible on the GithubMaker page.

Now that you are part of the GithubMaker community, welcome to the team 🍸.