Skip to content

New code review and Acceptance Process

Steve Kreisler edited this page Feb 10, 2022 · 4 revisions

The purpose of this document is to describe the steps through which new code or code updates are reviewed and accepted.

All new code and changes must be made through the pull request process. Code shall never be pushed into the repository.

Terms

  • upstream: Where you cloned the repository from
  • origin: Default name Git gives to the server you cloned from
  • branch: A version of the repository that diverges from the main working project
  • fork: A rough copy of a repository. Forking a repository allows you to freely test and debug with changes without affecting the original project.
  • pull request: A process for a developer to notify team members that they have completed a feature
  • push: upload local repository content to a remote repository
  • fetch: get branches and tags from one or more other repositories, along with the objects necessary to complete their histories

How to start

Requirements

Each pull request (PR) must meet the following criteria before it can be considered to be merged:

  • The code shall be PEP 8 compliant as defined by our flake8 configuration and meet standards of quality.
  • A changelog entry shall be included if the PR changes the behavior of any code.
  • All code shall provide adequate testing. The test coverage should not decrease, and for new features should be at or very close to 100%.
  • All code shall provide documentation. Each function and each class must have an associated documentation string in the correct format.
  • All continuous integration testing must pass.

If it is not possible to meet the above requirements, a SOC team member can provide a waiver.

Review Process

  • The following team members must review and accept all merge requests. This rule still applies if the merge request is made by a SOC team member or an instrument member.
    • At least one SOC team member
    • At least one relevant instrument team member
  • All new functionality shall be reviewed for relevance to the repository. Functionality that is common to instrument packages can be placed shared in a common Python package.

Merging

Once a PR is ready to be merged, the git commits should squashed into a single commit.

Clone this wiki locally