Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • 12-9-stable
  • 12-7-stable
  • 12-6-stable
  • 12-8-stable
  • github/fork/Kloppi313/patch-1
  • 12-5-stable
  • 12-4-stable
  • github/fork/ramalokesh8477/master
  • 12-1-stable
  • 12-2-stable
  • 12-0-stable
  • 12-3-stable
  • 42-42-stable
  • github/fork/hussamgit398/patch-2
  • 12-3-auto-deploy-20190911
  • 12-3-auto-deploy-20190916
  • 12-3-auto-deploy-20190908
  • 12-3-auto-deploy-20190901
  • 12-3-auto-deploy-20190901-32664
  • v12.10.0.pre
  • v12.9.0
  • v12.9.0-rc42
  • v12.8.7
  • v12.8.6
  • v12.8.5
  • v12.8.4
  • v12.8.3
  • v12.6.8
  • v12.7.7
  • v12.8.2
  • v12.8.1
  • v12.9.0.pre
  • v12.8.0
  • v12.8.0-rc42
  • v12.5.10
  • v12.7.6
  • v12.6.7
  • v12.7.5
  • v12.5.9
40 results

code_review.md

  • Kerri Miller's avatar
    cd2a503d
    Add a section of examples · cd2a503d
    Kerri Miller authored
    We have a fairly good guide to Code Reviews, but can be improved
    by adding a few examples of what a good code review looks like
    at GitLab, specifically ones where there is a bit of back and
    forth, "nit-picking," etc. This would:
    
    + help set expectations of newly hired engineers around what our
    process looks like when it is functioning what level of scrutiny
    their code will be under
    
    + how we have technical conversations
    
    + show by example how after you're done crafting a solution, there
    can still be extra work done either tidying up code and/or managing
    the communication and conversations about your proposed MR
    cd2a503d
    History
    Add a section of examples
    Kerri Miller authored
    We have a fairly good guide to Code Reviews, but can be improved
    by adding a few examples of what a good code review looks like
    at GitLab, specifically ones where there is a bit of back and
    forth, "nit-picking," etc. This would:
    
    + help set expectations of newly hired engineers around what our
    process looks like when it is functioning what level of scrutiny
    their code will be under
    
    + how we have technical conversations
    
    + show by example how after you're done crafting a solution, there
    can still be extra work done either tidying up code and/or managing
    the communication and conversations about your proposed MR