Skip to content

Latest commit

 

History

History
59 lines (39 loc) · 2.73 KB

CONTRIBUTING.md

File metadata and controls

59 lines (39 loc) · 2.73 KB

Your First Good Pull Request To StoneDB

Once the code is merged into StoneDB, your name will be stored in system.contributors table forever!

Prerequisites

Check if  git has been installed. If not, install it first.

Submit a PR

contributing.png

  1. Issue report: Open a regular StoneDB issue to bind your pull request.
    For more details about creating github issue concepts, see: create an github issue
  2. Fork StoneDB repo to your own account.
  3. After add you own code, add unit test
  4. Do make mtr test How to add mtr test
  5. After all test passed, use clang-format to formate your code according to google c++ styleguide
  6. Submit a Draft Pull Requests and  write your PR description
    For more details about pr concepts, see creating-a-pull-request-from-a-fork
    For more detail about draft pr concepts,  see draft-pull-request
  7. After all CI tests are passed, change the status to “Ready for review”.

Code Review

After the pr is reviewed, you may get a "LGTM", we'll merge your PR as soon as you've addressed all review feedback!

CR Jargon:
These are the acronyms you'll frequently encounter during code reviews.

  • CR, "code review"

  • PR, "pull request"

  • PTAL, "please take another look"

  • RFAL, "ready for another look"

  • LGTM, "looks good to me"

  • TF[YT]R, "thanks for your/the review"

PR Commit Message

Format: <type>(<scope>): description (#issue_id)
e.g.:

fix(util): fix sth..... (#3306)

[summary]
1 ...
2 ...

More types:

  • feat: (new feature for the user)
  • fix: (bug fix for the user)
  • docs: (changes to the documentation)
  • style: (formatting, missing semi colons, etc; no production code change)
  • refactor: (refactoring production code, eg. renaming a variable)
  • test: (adding missing tests, refactoring tests; no production code change)
  • chore: (updating grunt tasks etc; no production code change)