We welcome new contributions! This page is a short overview to get you started. The full contribution guide, which also covers documentation builds and performance profiling, lives in doc/contributing.md and is rendered as part of our documentation.

Everyone participating in this project is expected to follow our Code of Conduct.

If you run into a problem or have a question about using micro-sam, please open an issue or reach out via image.sc using the tag micro-sam. You do not need to write code to help us: good bug reports and documentation improvements are valuable contributions.

Before you start working on a larger change, please open a new issue to discuss your idea. This lets you ask questions, and lets the current developers suggest the best way to implement it before you invest time in it.

We use git for version control and conda to manage environments. Clone the repository and check out the development branch:

$ git clone https://github.com/computational-cell-analytics/micro-sam.git
$ cd micro-sam
$ git checkout dev

Then create the environment, install the user and developer dependencies, and install micro-sam as an editable installation:

$ conda env create -f environment.yaml
$ conda activate sam
$ python -m pip install -r requirements-dev.txt
$ python -m pip install -e .

Changes are made branching off from the development branch:

$ git checkout dev
$ git checkout -b my-new-feature

We use google style python docstrings for all new code. The Python library documentation is a good starting point for understanding how the micro-sam code is organized.

The tests are run with pytest:

$ pytest

New code needs tests to go with it. We prefer small unit tests over integration tests; if your code is hard to unit test, it usually needs to be broken into smaller functions. See the full guide for details on testing napari-based code and on code coverage.

Once your changes are ready, open a pull request against the dev branch, not main. You can mark it as a draft while you are still working on it and still discuss the best approach with the maintainers.

Please describe what your pull request changes and why, and link the issue it addresses. The continuous integration runs the tests for your pull request; a maintainer will review it and may ask for changes before merging.