status-im/status-go
1
0
Fork 0
mirror of https://github.com/status-im/status-go.git synced 2026-08-27 15:11:09 +00:00
Code Issues Packages Projects Releases Wiki Activity
Page: Code Review
Pages
Additional JSON RPC API Building Code Review Contact Contributing Deployment FAQ Glossary of Terms Home Modifying code in go ethereum Notes on Bindings Rebase go ethereum Status CLI command: statusd Style Guide Testing Updating CHT BloomTrie Usage Patterns Whisper Push Notifications
Clone
1
Code Review
b00ris edited this page 2017-11-14 12:02:12 +03:00
Table of Contents

Motivation and fundamental principles

  • The main CR target is to approve PR.
  • Status wants the CR process to be transparent for all his contributors.
  • We want to move as fast as we can.

This doc is a set of rules («SHOULD»s and «SHOULD NOT»s) that all core contributers are agreed with. It is not a finish state of the document more of a way a live iterative process. Core contributers SHOULD keep in mind that any PR brings a value. The new version of this document should be approved by all core developers.

CR rules

  1. PR should be approved and merged into upstream if TWO OR MORE core developers have approved it and if there is no any cause of reject with the point of the current document.
  2. CI should pass successfully.
  3. PR should work according the issue or the bug and only according it. PR should solve the issue which set in the task and only the ussue.
  4. Any code addition or changing should be covered with proper tests.
  5. PR should not contain a commented code.
  6. Comments like TO DO or FIX ME should be named, e.g. // todo(@jeka): remove after task#000.
  7. Any refactoring should be described in PR: what, where and why something has beed changed.
  8. The changes in a vendored go-ethereum should be done as described in https://www.notion.so/status/Modifying-go-ethereum-245a078dde834b87aa7e4e9b4e8cc6ec

Project Information

Getting started

Developers

Support

Internal