Skip to content

Latest commit

 

History

History
46 lines (31 loc) · 3.49 KB

CONTRIBUTING.md

File metadata and controls

46 lines (31 loc) · 3.49 KB
Raw

Contributing

Thanks for considering contributing to Vonage Ruby skeleton app. From typos, code and beyond, we truly appreciate and welcome input from everyone.

You can read all about our markdown additions, writing style guide and standard placeholders on our Contributing page. Once you have a change to share with us, read on ...

Git process

This project uses GitHub Flow. We are happy to have issues opened for discussion, but we don't require an issue to be created before a pull request is opened. When you have a change you want us to consider:

  • Create a new branch on your own fork, from an up-to-date master branch.
  • Make the changes on that new branch.
  • Open a pull request for us, making sure to tell us what you changed and why in the pull request title and description. Pull requests without a meaningful title and a completed template may be closed.

If you need more information about how to do any of the above, we recommend the GitHub Help pages, which are indeed very helpful.

Tips:

  • Keep it small! Small changes are easy to review and more likely to be accepted. More involved changes probably need discussion first.
  • Tell us what changed and why. This helps us to understand the change and get the right people to review it.

For maintainers/reviewers

  • If you know who can review a particular pull request, tag those people. Tagging a few can be useful as we're in different timezones and can often be travelling.
  • Review with an eye to accuracy and maintainability as well as correctness. Ask yourself "do we want this change?" and "will users find this information here, could it be added to existing docs?" as well as "is everything spelled correctly?"
  • Before accepting a change, check that the markdown renders as expected, and the code runs ... this probably means either pulling the code down to your development platform or deploying a review application.
  • If changes are needed, then either:
    • make the changes yourself (especially for minor or editorial changes).
    • set your review as "changes requested" and comment for what is needed to make this pull request ready to accept.
  • If everything is good then go ahead and approve the pull request.
  • Now merge the pull request! If the change is good to go, then it should go (unless there are special circumstances of course). In the main, anyone can merge an accepted pull request at the earliest opportunity.
  • Delete the branch if it's on our repo.

Work in Progress [WIP]

  • Please feel free to open a pull request when you are at the early stages of working on something. Put "[WIP]" in the title so we know it's not ready yet.
  • Work in progress has a cost, merging things that have been branched for a long time can be harder work and cause more issues than smaller changes that can be completed quickly. Please consider whether to start a task that you can't finish in the time you have available.
  • Inactive pull requests will be closed. When you are ready to complete the work, please rebase your branch and open a new pull request.

GitHub Pull Request Labels

We use a few different labels for our pull request workflows:

  • don't merge for things that might need external review, or where it needs to be merged on a specific date, or to clearly note that things are not ready yet!
  • help wanted when anyone is welcome to dive in.
  • stale when the pull request is abandoned and will soon be closed.