callowayproject / bump-my-version

A small command line tool to simplify releasing software by updating all version strings in your source code by the correct increment and optionally commit and tag the changes.
https://callowayproject.github.io/bump-my-version/
MIT License
243 stars 17 forks source link

Project sustainability & governance #161

Open mfisher87 opened 3 months ago

mfisher87 commented 3 months ago

Hello! Currently there are two active projects I know of in this space: bumpver (also inspired by bump2version) and this one. In terms of activity and my subjective perception of sustainability, they seem fairly similar; similar number of contributors and stars on GitHub. I've used both this project and bumpver before. I'm making this post on both repositories (link to post on bumpver).

There's been a history in this space of projects dying off because the repo administrators became unavailable to continue their role (bumpversion, bump2version). Forks happened and that's great that the work continues, but I'd really like to see a stable long-running project that solves this problem and helps focus our resources.

One of the main reasons I use a version-bumping tool instead of relying on Python packaging tools that can read my Git tags is because I often write software that needs to have a DOI, and the code metadata that's used to generate DOIs needs to be kept in sync with the software version. Other metadata items like release date need to be automatically updated. Have you considered adoption by, for example, Scientific Python or pyOpenSci to provide governance and help focus community resources around the needs this project serves?

coordt commented 3 months ago

There has been nothing to consider, as no group has offered.

The biggest problem with sustainability and governance is gaining active participation by more than one person. A project needs participants before it needs governance.

If you have ideas to foster community collaboration and participation, I would love to hear about it.

mfisher87 commented 3 months ago

Thanks for your response, Corey!

As a preface to everything else, I don't know that the organizations I mentioned are actually great options for this library; at this point I'm just spitballing. Different orgs will have very different expectations/value propositions, and an "open science" org comes to mind as adoption of CITATION.cff for the Zenodo-GitHub integration is increasing, and tools like this are the best/only way (that I know of) for a Python project to keep the data in that file in sync with the software version and release date. I feel it's likely that future efforts will build on bumpversion-type tools to robustly document how to use them to make scientific software more citable and to automate their use to be as accessible as possible to ease researchers and research software engineers onboarding to this new concept.

There has been nothing to consider, as no group has offered.

In the case of pyOpenSci, there's an application process. They have a pre-submission inquiry process that can be used as well. If you'd like help with the process or justifying the use case for scientific software, I'd be happy to help out! Here are pyOpenSci's post-acceptance expectations. I have limited experience with this, but a co-worker of mine just got their software accepted to pyOpenSci, so I think we could look to them for more details. We've been pestering them to give a presentation about it; maybe we can set it up so you can join on Zoom. Would you be interested?

The biggest problem with sustainability and governance is gaining active participation by more than one person. A project needs participants before it needs governance.

If you have ideas to foster community collaboration and participation, I would love to hear about it.

I think getting the project adopted will help a lot with this. Orgs that offer this type of incubator service can do things like feature your project in social media outreach and blog posts, and add you to a larger org-level maintainer community where you can source collaborators. Just name recognition can do a lot to make people feel welcome as a contributor; making people feel welcome can be a lot of work as an individual maintainer. If pyOpenSci doesn't seem like a good fit, I'd be happy to help out looking for alternatives, just let me know! I'd really like to help ensure that we have stability in this space, because as I mentioned above, folks including myself are going to be building out educational materials for researchers, and library churn will lead to maintenance work on those materials.

In lieu of applying to an org, the most consistent success I've had is using the good first issue label to attract contributors. It just works. I don't have any accounts on any social media sites (you could argue GitHub has social media features, but that's beside the point), so I'm not very good at the marketing and outreach stuff :)

Zeitsperre commented 1 month ago

Hi there,

I'm thrilled to see this point being brought up. I've been relying on bump*version projects to not have to rely on GitHub-specific functionality across the many projects I maintain, and this fork in particular is really helpful for my work.

PyOpenSci is a great fit for a project like this (full disclosure, my software has been reviewed and accepted by them, and I am also editing my first submission for PyOS). The review process is really not too cumbersome, and the end result is a project that will not only be improved from a maintenance and tooling standpoint, but will also benefit from a community of research software developers that can help with finding maintainers or taking on maintenance tasks if ever you need to step away from the project.

There would be some work to get things compliant, but the reviewer/editors would be the ones to help guide you through it (or even contribute Pull Requests). Personally, I would love to see more mission-critical software adopt best practices with maintenance and community management.

I think it would be worthwhile to open an issue at PyOS. You could even mark that I would be comfortable taking part in the review process (as a reviewer).