github.com/gophercloud/gophercloud@v1.11.0/docs/contributor-tutorial/step-06-code-review.md (about)

     1  Step 6: Code Review
     2  ===================
     3  
     4  Once you've submitted a Pull Request, three things will happen automatically:
     5  
     6  1. Travis-CI will run a set of simple tests:
     7  
     8      a. Unit Tests
     9  
    10      b. Code Formatting checks
    11  
    12      c. `go vet` checks
    13  
    14  2. Coveralls will run a coverage test.
    15  3. [OpenLab](https://openlabtesting.org/) will run acceptance tests.
    16  
    17  Depending on the results of the above, you might need to make additional
    18  changes to your code.
    19  
    20  While you're working on the finishing touches to your code, it is helpful
    21  to add a `[wip]` tag to the title of your Pull Request.
    22  
    23  You are most welcomed to take as much time as you need to work on your Pull
    24  Request. As well, take advantage of the automatic testing that is done to
    25  each commit.
    26  
    27  ### Travis-CI
    28  
    29  If Travis reports code formatting issues, please make sure to run `gofmt` on all
    30  of your code. Travis will also report errors with unit tests, so you should
    31  ensure those are fixed, too.
    32  
    33  ### Coveralls
    34  
    35  If Coveralls reports a decrease in test coverage, check and make sure you have
    36  provided unit tests. A decrease in test coverage is _sometimes_ unavoidable and
    37  ignorable.
    38  
    39  ### OpenLab
    40  
    41  OpenLab does not yet run a full suite of acceptance tests, so it's possible
    42  that the acceptance tests you've included were not run. When this happens,
    43  a core member for Gophercloud will run the tests manually.
    44  
    45  There are times when a core reviewer does not have access to the resources
    46  required to run the acceptance tests. When this happens, it is essential
    47  that you've run them yourself (See [Step 4](step-04.md)).
    48  
    49  Request a Code Review
    50  ---------------------
    51  
    52  When you feel your Pull Request is ready for review, please leave a comment
    53  requesting a code review. If you don't explicitly ask for a code review, a
    54  core member might not know the Pull Request is ready for review.
    55  
    56  Additionally, if there are parts of your implementation that you are unsure
    57  about, please ask for help. We're more than happy to provide advice.
    58  
    59  During the code review process, a core member will review the code you've
    60  submitted and either request changes or request additional information.
    61  Generally these requests fall under the following categories:
    62  
    63  1. Code which needs to be reformatted (See our [Style Guide](/docs/STYLEGUIDE.md)
    64     for conventions used.
    65  
    66  2. Requests for additional information about the validity of something. This
    67     might happen because the included supporting service code URLs don't have
    68     enough information.
    69  
    70  3. Missing unit tests or acceptance tests.
    71  
    72  Submitting Changes
    73  ------------------
    74  
    75  If a code review requires changes to be submitted, please do not squash your
    76  commits. Please only add new commits to the Pull Request. This is to help the
    77  code reviewer see only the changes that were made.
    78  
    79  It's Never Personal
    80  -------------------
    81  
    82  Code review is a healthy exercise where a new set of eyes can sometimes spot
    83  items forgotten by the author.
    84  
    85  Please don't take change requests personally. Our intention is to ensure the
    86  code is correct before merging.
    87  
    88  ---
    89  
    90  Once the code has been reviewed and approved, a core member will merge your
    91  Pull Request.
    92  
    93  Please proceed to [Step 7](step-07-congratulations.md).