We need more roadies in jazzband

[Mogost]

There is a feeling that too much load fell on @jezdez . It would be worthwhile to find someone else who would take on this role. I think at least another 2-3 people should be with this role.
Perhaps one might think about co-roadies role.

[jezdez]

Thanks for raising this, indeed this isn't just a feeling, but in the past few months in particular (and also to some extent before) it was harder for me to make time in my spare time between my personal health issues in February and March and then the lock down that had a tremendous impact on the amount of spare time for working on Jazzband.

I have had plans to extend the roadies again and had multiple people reach out to me and volunteer. Whether that's still the case under the current situation with the impact of COVID-19 on everybody's life I don't know yet. I still plan to roll out those changes over the course of the coming months. Please stay tuned and thanks for raising the issue here.

[jstockwin]

Hey! Whilst I've not had much interaction with JazzBand before, I'd be very happy to help out and can give at least a few hours each week.

I/my company use quite a few JazzBand maintained packages, and have done so for a while. We'd love to give some time back and help out. For example, we'd be happy to take over project lead on some packages (e.g. see #195, which is from a colleague). I appreciate there's a different between a Roadie and a Project Lead, but I'd personally be happy to do some of the more admin-related tasks of a Roadie.

Is it possible to have a few basic details of what this would entail? (I.e. time commitment, the sorts of tasks expected, etc).

Thanks!

[manelclos]

Hi @jezdez, I'd like to become a Roadie, or help in some way. In the past months where you were unavailable I felt like being in the same situation as with those great projects that are not maintained any more, i.e. Jazzband itself suffering from the same problem it wants (and it is!) solving. Please add more Roadies, and keep up the good work!

[Archmonger]

@jezdez This is becoming a critical issue. Several projects within Jazzband are facing deprecation due to inactive project leads (with no way appoint new ones), and several incoming project proposals aren't getting pulled into Jazzband.

I'm willing to volunteer as a roadie if it means we can maintain the longevity of everything under the Jazzband umbrella.

[Archmonger]

@jstockwin @aleksihakli @manelclos

Since it has been over a year, I'm reaching out to previous participants on this thread to see if individuals still have an open interest in becoming roadies.

Reply back (or add an emoji reaction to this comment) if you're still available for volunteering for this.

I'll pester jezdez some more about this once I confirm everyone's availability 👀

[jstockwin]

Still available and happy to help out where I can

[aleksihakli]

I'm happy to help as well 👍

[Archmonger]

@jezdez Would you be available to start considering more roadies? We have open interest from 4 individuals from this thread alone.

As I mentioned before, every day that passes by this issue becomes more critical.

[jezdez]

@jezdez Would you be available to start considering more roadies? We have open interest from 4 individuals from this thread alone.

I'm not able to restart this at this very moment given my other responsibilities, but plan to focus on this towards the end of the year. I have a good list of volunteers already and the people who voiced it here are on it as well.

For the record, the work to apply for the PSF fiscal sponsorship used up a lot of time in the first part of the year and took over six months to get done. Those were the changes I mentioned above in my comment in June last year, and they were essential to put Jazzband on the path to a better sustainable maintenance model. One of the benefits is the ability to collect US tax-deductible donations that can eventually allow us to provide grants to people working on the Jazzband organization and infrastructure.

I've always considered expanding the roadies as the next logical step (together with a formal proposal system like Python's PEPs), but I simply haven't gotten to it yet. Adding new roadies is not just flipping a switch but requires generalizing things that so far never had to be shared with multiple people, e.g. credentials, server access, documenting core values to guide new roadies etc. As you can imagine that basically takes a bit of time, which I haven't had since May.

As I mentioned before, every day that passes by this issue becomes more critical.

I appreciate you repeating this, it's really noted and not ignored. That said, this is a volunteer-run project, so adding pressure like this is kind of moot. I'd appreciate if you would stop "pestering" me, as you said above. Much appreciated :)

[MrCordeiro]

It's bad that activity for this issue has died down. A bus factor of 1 is a very worrisome place for any project to be - particularly a volunteer-run one.

[dopry]

@jezdez In your last update, you said you were planning to focus on this issue again at the end of 2021. Do you have any updates at this time?

[ssbarnea]

10000 foot view of this: almost two years and nothing happened. We can conclude that regardless pure intentions, a bus factor of one can be really problematic as soon the bus runs out of fuel.

I worked with @atugushev to help with pip-tools project maintenance for quite some time but I still hit lots of walls. Unable to configure different options to the project and today, when we needed to make an urgent release, i realised that making a release on github was not enough to make the release. I still have to open a ticket to get the release published. Bureaucracy.

That is not the first case where I seen community asking for extending the list of people with rights... and the answer being some kind of we need more money/sponsoring. I seem the same thing happening with cookiecutter project, where the project is effectively killed because they refused to give access to more people (we repeated delays and various excuses). Due to this nobody was able to make a release on pypi for a very long time and slowly many of those that helped lost hope and moved away.

Was the original goal of jazzband to help python project reduce maintenance burden or to create a single-point of control? Looking at https://jazzband.co/roadies I wonder if that is a community of size one,... hopefully not by design.

IMHO, once we open the money question, we already lost it. I would personally focus on ensuring that there are at least 5-10 people on that page. Just check that they can be trusted, and that should be enough.

[aleksihakli]

To expand on this: we need to expand the maintainer or roadie group. At the current evolution we have a degradation of capabilities as well as trust for the sustenance and maintenance model, which will lead to projects migrating away from the Jazzband organization in the long run.

I'd see a few options for expanding the organization as-is:

1. Just elect at least a couple (e.g. 2-5) maintainers from the volunteers by organizing a vote with some confidence mechanism; or
2. Since Jazzband is maintaining dozens of high-profile Django packages, maybe we could ask a few of the established maintainers to partake in the maintenance, forming a commission of maintenance from trusted individuals; or
3. We could also ask either DSF or PSF for guidance for electing a maintenance body for the project.

We need to solve this so that we have a viable model available for the continuance of this project.

[ssbarnea]

To be honest, I was about to request transfer of pip-tools to pypa, as that org will be much better suited for maintenance of the project. We already have examples like pipx which did the same. Sadly that is an unique case that would not apply for other projects, so I hope we will address this issue soon and avoid making others leave.

Full dependency on a single person is not acceptable anymore, there is too much at stake to have a single point of failure. With all due respect, there are plenty of reasons why things can go really bad for this organisation. There are lots of people inside the org dedicated to open source and trustable, pick at least two more.

[mattseymour]

Related ticket in jazzband issues #281, would be more than happy to help put time in to support this project. Maybe there could be a breakdown so we have roadies focusing on specific actions and points. I completely understand there needs to be a united front to make sure the project maintains its high standards as more roadies become active.

[frankwiles]

@jezdez I'd want to chat real quick about day to day duties and if part of the plan can be to bring in a third or fourth Roadie, likely people we both know and trust, to help spread the work load around.

But yes, I'm interested!

[hugovk]

However, may I suggest an incremental approach? At a minimum, giving a second roadie extra permissions for GitHub would unblock a lot of the bottlenecks we're facing.

@hugovk Good suggestion! Are you volunteering by any chance?

Sure, why not :) Would be good to join the quick chat with you and @frankwiles.

[sidmitra]

I'd be open to volunteer a few hours a week to do any legwork required to unblock stuff. Being a full "roadie" involves some level of trust i assume, hence seems like a large decision(i'm not sure of the full responsibilities yet). The alternative might be to adopt some people as "half-roadies" with limited responsibilities and a slightly easier decision to make and unmake if needed?

[dopry]

@hugovk @frankwiles @jezdez any forward movement on anointing additional roadies?

[hugovk]

Nothing yet.

[dopry]

@jezdez Any updates on adding additional roadies? It's going on 3.5 years now that you are the sole roadie. You mentioned multiple times that you have lists of volunteers. I can count quite a few in this thread. I'm sure the wider community appreciates your good intentions. You pose a significant keyman risk for not just the projects under the jazzband umbrella, but the wider community that uses them! If anything were to happen to you, releases would be blocked, including security updates and critical bug fixes. Admittedly, there are ways to work around them by appealing to support for pypi, github, etc, but it would be a chaotic process with lots of opportunity for social engineering to create wide risks for our community of users. It would be great to see you address this to ease the burden on yourself as well as mitigate the risk to the wider community.

[rayrrr]

Just a vote of confidence for @hugovk, who has been helpful in more than one occasion for me with issues in the geojson package.

[Mogost]

It's been three years since I opened that ticket.
As the author of this ticket, I would also gladly support designating @hugovk, as a roadie or co-roadie. I think a move like this, after three years, is reasonable. And the presence of so many comments here clearly shows that the problem is still relevant.

[thibaudcolas]

For people looking at Jazzband as an option, I thought I’d take a moment to share alternatives. Lots of us obviously would love to see initiatives like this succeed, but the management issues here have been clear for years, and their consequences very well summarized by @dopry in the above comment.

Alternative 1: "fork" Jazzband

This is what we’ve done for django-recaptcha. GitHub and PyPI have a lot of facilities these days to "run your own Jazzband". The rough steps are:

1. Create a new free GitHub organization for your project, transfer the project there.
2. Create a branch protection rule so changes can only be merged with at least one approving review, so all work needs at least two people involved.
3. Use GitHub Teams with appropriate access levels. My suggestion: one team per role supported by GitHub; read-only "Contributors"; Triagers; "Write access" Committers; Maintainers; Admin. Admins in particular; and organization owners; are critical in managing other members (adding new members, changing permissions)
4. Set up trusted publishing for PyPI, to publish package releases via GitHub Actions. This is a key recent improvement, so there’s no need to share PyPI access more than strictly needed.

Then off you go! This set of team roles makes it easy to convert package users to maintainers as they gradually prove themselves over time, moving from "org members", to "triagers", "contributors", "maintainers". In the future this might be even simpler to manage on the PyPI side with PyPI Organizations.

Alternative 2: Wagtail Nest

This is a "fork of Jazzband" that’s been operating a while, for Wagtail packages. The big difference is the "roadie" tasks are done by the Wagtail core team, with 21 members, 9 of which are trusted with "admin" access to the organization.

Those people are in #package-maintainers on the Wagtail Slack if anyone wants more info.

Alternative 3: find independent "roadies"

With Trusted Publishing, I think it’s worth saying the only access that’s needed for most tasks is committing in GitHub. If you’re comfortable to stay involved as an "admin", you can go quite a long way adding people as "Outside collaborators" in GitHub where your project is currently. The only drawback here is that those people can’t have permissions to add other collaborators, so there’s still a bottleneck.

---

Finally I thought I’d mention there’s a #packages channel on Django’s Discord server, which is meant to foster collaboration between package maintainers.

[ncoghlan]

Not a solution in any way, but a reminder that the "transitive trust" problem involved in recruiting new roadies to a project like Jazzband (when choosing a new roadie or roadies to trust, @jezdez is propagating the trust previously granted by all participating projects) isn't just a hypothetical concern: https://en.wikipedia.org/wiki/XZ_Utils_backdoor

The concerns discussed in https://www.harihareswara.net/posts/2024/trust-new-maintainer/ apply to any open source project, but they're particularly significant for a collective org like JazzBand

[blaisep]

IMHO, the trust management is still a legitimate, outstanding item.
The other part of the conversation I had with @jezdez at PyconUS2024 consisted of my perspectives on the importance of reducing toil and increasing shared understanding.
I know that @hugovk and @frankwiles , et al. are fans of automation in pipelines and in docs.

Examples of complex projects with automated docs:

• https://developer.skatelescope.org/en/latest/tools/ci-cd/continuous-integration.html
• https://docs.python.org/3/

[hugovk]

See also @sethmlarson's proposal:

• RFC: Adopt new security model for publishing #364

Seth is the PSF's Security Developer in Residence: https://pyfound.blogspot.com/2023/06/announcing-our-new-security-developer.html

And has been doing lots of good work to improve the security, and along the way, maintainability of CPython: https://sethmlarson.dev/blog