Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be explicit about test coverage and add footnotes #190

Merged
merged 5 commits into from
Jul 26, 2024
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,8 +40,8 @@ How does the package use scverse data structures (please describe in a few sente
- [ ] The code is publicly available under an [OSI-approved](https://opensource.org/licenses/alphabetical) license
- [ ] The package provides versioned releases
- [ ] The package can be installed from a standard registry (e.g. PyPI, conda-forge, bioconda)
- [ ] The package uses automated software tests and runs them via continuous integration (CI)
- [ ] The package provides API documentation via a website or README
- [ ] The package uses automated software tests that cover all public functions and runs them via continuous integration (CI)[^1]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the correct expectation but a rather strong one. I'm fine with it but wonder what other people think. Maybe a quick question for zulip?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is strong, but maybe it can be made less imposing by adding a paragraph about what a public API should be.

I think we should advise people to rather make their public API smaller than to compromise its testing or documentation.

In anndata, we recently documented the callback parameter signature of anndata.experimental.read_dispatched and in the process discovered what we had made implicitly public (if experimental).

To avoid a bunch of private things being made public, we made it all more correct and slimmer, which improved clarity here a lot.

- [ ] The package provides API documentation via a website or README[^2]
- [ ] The package uses scverse datastructures where appropriate (i.e. AnnData, MuData or SpatialData and their modality-specific extensions)
- [ ] I am an author or maintainer of the tool and agree on listing the package on the scverse website

Expand All @@ -55,3 +55,7 @@ How does the package use scverse data structures (please describe in a few sente
- Mastodon:
- [ ] The package provides tutorials (or "vignettes") that help getting users started quickly
- [ ] The package uses the [scverse cookiecutter template](https://github.com/scverse/cookiecutter-scverse).

[^1]: Continuous integration means that software tests are automatically executed on every push to the git repository. This guarantees they are always run and that they are run in a clean environment. Scverse ecosystem packages most commonly use [GitHub Actions](https://github.com/features/actions) for CI. For an example, check out our [cookiecutter template](https://github.com/scverse/cookiecutter-scverse).

[^2]: By API documentation, we mean an overview of _all_ public functions provided a package, with documentation of their parameters. For an example, see the [Scanpy documentation](https://scanpy.readthedocs.io/en/stable/api/preprocessing.html). In simple cases, this can be done manually in a README file. For anything more complex, we recommend the [Sphinx Autodoc plugin](https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html)
Loading