PRs

• OK to branch from https://github.com/single-cell-data/TileDB-SOMA -- no need to fork-and-branch (although you can if you like)
• Follow the PR template
• Pro-tip: alias pav='python -m pre_commit run -a -v' before submitting the PR, to catch CI issues before they reach GitHub

Branches and releases

See https://github.com/single-cell-data/TileDB-SOMA/wiki/Branches-and-releases.

Top-level namespacing

• Items in the top-level namespace should include things we expect a user to instantiate themselves or call directly
• Exception: helper packages such as tiledbsoma.io
• Anything storage-dependent should include the storage engine as a prefix or submodule: e.g. soma.tiledb_foo()
  • For Python: prefix or submodule
  • For R: use a prefix since there are no submodules in R

Sandbox setup

• Python: https://github.com/single-cell-data/TileDB-SOMA/blob/main/apis/python/README.md
• R: https://github.com/single-cell-data/TileDB-SOMA/blob/main/apis/r/README.md
• C++: https://github.com/single-cell-data/TileDB-SOMA/blob/main/libtiledbsoma/README.md

Automated QA

• These run in CI, so you can run them locally (in apis/python) before putting up a PR: black, isort, flake8, mypy, python -m pytest tests
• See also #193 for an opt-in way to use pre-commit hooks, if you prefer

Coding and code review

• 1 reviewer suffices unless stated otherwise, unless explicitly:
  • If the author wants more than one approval, they should @-tag the people they need
  • If the one accepting reviewer says "LGTM, but I lack enough context on ____ to be sure" they should say so (and, ideally and if possible, @-tag someone who they think would be a good second approver)
• Squash-and-merge is preferred