You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Find a better place for our contributors guide than linking to scanpy one #266
changed the title [-]Find a better place for a contributors guide[/-][+]Find a better place for our contributors guide than linking to scanpy one[/+]on Aug 23, 2026
I think we kind of need at least two versions: one for more stability focused projects that do backports, towncrier, … and one for faster dev cycles where a feature landing on main means the next release is a minor release.
But I don’t know how much we should standardize, e.g. Ilan convinced me to do conventional commits, but it took me a while to get used to it and understand the different tags. It integrates nicely with backports and towncrier, but for the fast-paced kind of project it would be kind of a chore with no benefit other than a pretty commit log when you use refined github:
That's true. Another challenge is that we haven't standardized release notes across our org yet. I'd love to do this but I fear it'll be hard to convince you to switch from towncrier to something simpler that we can adopt everywhere.
So maybe there's a way to have a general version that we can always link to which can be extended/amended by packages that need more (like anndata or scanpy)?
@LucaMarconato@flying-sheep@grst is it too weird if we also have such a guide on our main page? Are our packages deviating too much from the template? I better hope not. If not, we can write a general version that all of our frameworks must adhere + some custom comments per package if necessary.
Activity
[-]Find a better place for a contributors guide[/-][+]Find a better place for our contributors guide than linking to scanpy one[/+]flying-sheep commentedon Aug 24, 2026
I think we kind of need at least two versions: one for more stability focused projects that do backports, towncrier, … and one for faster dev cycles where a feature landing on
mainmeans the next release is a minor release.But I don’t know how much we should standardize, e.g. Ilan convinced me to do conventional commits, but it took me a while to get used to it and understand the different tags. It integrates nicely with backports and towncrier, but for the fast-paced kind of project it would be kind of a chore with no benefit other than a pretty commit log when you use refined github:
Zethson commentedon Aug 24, 2026
That's true. Another challenge is that we haven't standardized release notes across our org yet. I'd love to do this but I fear it'll be hard to convince you to switch from towncrier to something simpler that we can adopt everywhere.
So maybe there's a way to have a general version that we can always link to which can be extended/amended by packages that need more (like anndata or scanpy)?
Zethson commentedon Sep 23, 2026
https://nf-co.re/docs/contributing/
https://nf-co.re/docs/contributing/contribute-existing-pipelines
...
@LucaMarconato @flying-sheep @grst is it too weird if we also have such a guide on our main page? Are our packages deviating too much from the template? I better hope not. If not, we can write a general version that all of our frameworks must adhere + some custom comments per package if necessary.
grst commentedon Sep 24, 2026
I think by now we are relatively standardized. (Almost) all packages use the template now, we are aligned on using hatch, etc.
We could just link to https://cookiecutter-scverse-instance.readthedocs.io/en/latest/contributing.html?