docs/howto/how-to-contribute.md

   1 # How to Contribute
   2
   3 **ONE** always welcomes your contribution, but there are basic guidelines that you should follow in
   4 order to make your contribution be accepted.
   5
   6 This document explains such guidelines for beginners.
   7
   8 ## General contribution guidelines
   9
  10 If you are not familiar with git or github, please visit
  11 [here](https://guides.github.com/activities/hello-world/) for basic understanding of git and github.
  12
  13 ## How to create a Pull Request
  14
  15 This section explains the steps to create a pull request (PR).
  16
  17 1. Create an issue
  18
  19    Maintainers will accept your contribution only when it is well aligned with the
  20    [roadmap](../overview/roadmap.md) and design
  21    principles of **ONE**. So, it is optional, but recommended for contributors to create an issue
  22    and have a discussion with maintainers before writing code.
  23
  24 1. Create a draft PR
  25
  26    Maintainers will accept your pull request only when it is **reasonably small** and **focused**.
  27    Sometimes, your contribution may require huge and loosely-coupled changes. You **should** split
  28    your contribution into multiple small, but focused pull requests in this case. Unfortunately, it
  29    is possible that maintainers reject your pull request as it is hard for them to understand the
  30    intuition behind these changes. So, it is optional, but recommended for contributors to present
  31    the full [draft](https://github.com/Samsung/ONE/pulls?q=is%3Apr+label%3ADRAFT+) of your
  32    contribution and have a discussion with maintainers before creating PR(s).
  33
  34 1. Create a commit
  35
  36    It is time to create a commit for submission once you are convinced that your contribution is
  37    ready to go. Please include signed-off message at the end of commit message. If not, your pull
  38    request will be **rejected** by CI.
  39
  40 1. Check code format locally
  41
  42    **ONE** has its code formatting rules, and any pull request that violates these rules will be
  43    **rejected** by CI. So, it is optional, but recommended for contributor to check code format
  44    locally before submission.
  45
  46 1. Create a PR
  47
  48    It is time to send a pull request. Please explain your intention via description. Maintainers
  49    will review your pull request based on that description. Each pull request needs approval from at
  50    least two reviewers to be accepted. Note that **description should include at least four words**.
  51    If not, your pull request will be **rejected** by CI.
  52
  53 1. Request review
  54
  55    It is recommended to assign reviewers yourself. Maintainers will honor your review request,
  56    and accept your pull request only when
  57
  58    - Approved by 1+ reviewers
  59    - 0 rejection(Request Changes)
  60    - 0 pending review request
  61    - All the reviewers in the list must approve your pull request
  62
  63    You can add/remove pending review requests in the middle of the review process. Maintainers
  64    (or reviewers) could review your pull request even without explicit review request.
  65
  66 1. Update per feedback
  67
  68    Sometimes, maintainers (or reviewers) will request changes on your pull request. Please update
  69    your pull request upon such feedbacks. These update commits will be squashed into the first
  70    commit of your pull request later. Please do **NOT** include a sign-off message or write a full
  71    description for update commits.
  72