maintaining packages in our lab

[aryarm]

It would be great if we could have a doc on our wiki that extends bioinfo-ucsd/wiki#5 and provides some tips on how to set up a package/tool in our lab so that others can maintain the package once the original author leaves the lab. Some things we could include:

• the package should be in our GitHub org so that everyone has push access to it
• the repo should have main branch protections and PRs should ideally require at least one review from anyone in the lab. Nice to have: branches should get deleted automatically upon PR merging
• upon transfer into the lab org, an admin of our org should create a GitHub team comprised of designated "maintainers" of the project, who should get admin access to the repo
• pypi trusted publishing should allow others to publish new pypi versions without needing access to the original pypi account
  • and ideally a GitHub actions workflow for publishing so that anyone (even those who aren't maintainers) can trigger a release
  • a GitHub environment that requires approval of all releases by the "maintainers"
• in case access to the original pypi account is needed, Melissa should be assigned as a collaborator of the pypi account
• Melissa should be assigned as a collaborator of the readthedocs account
• the readthedocs account should allow for PR previews
• ideally, the readthedocs account will have both a "stable" and "latest" version and automatic versioning enabled
• the GitHub team should be listed as a maintainer in the corresponding bioconda recipe, if there is one (it turns out that this actually doesn't work, after all)
• ideally, a .devcontainer.json file should be available in the repository to automatically and reproducibly set up a dev environment through github codespaces
• should also mention python version deprecation policy:
  When a python version becomes "end of life", we officially stop supporting it (by stating that it is no longer supported in release notes and our documentation), but we continue to unofficially support it by allowing in our pyproject.toml and meta.yaml files. We no longer use it as our development version (ie the version that gets installed in our devcontainer and is expected in our lock file), but we continue to run our CI checks for it. Once those CI checks break (which can happen at any time and for any reason), we update our pyproject.toml and meta.yaml files accordingly and remove the CI checks. However, we will always continue to maintain working CI checks for all officially supported versions.

[aryarm]

it might also be good to have a doc that lists some tips for writing and reviewing PRs

We can refer to the section "Regarding your broader point about PR etiquette:" in the discussion in gymrek-lab/TRTools#201 (comment) for some thoughts on this

Here are some things we could include:

• GitHub codespaces allows you to test the code, suggest edits, and review PRs
• you can place breakpoints in the code to check that something is tested
• writing suggestions within your comments