Schade das der Maintainer des Debian-Paketes nicht ansatzweise die Funktionalität eines Passwortmanagers verstanden hat. Meiner Meinung nach missbraucht hier ein Paketbetreuer seine Kompetenzen. Letzlich schadet er mit seiner Vorgehensweise Debian insgesamt als Linuxdistribution.
I'm going to host an online workshop for the Gentoo e.V. on 2024-06-15 about how to "Host Gentoo dependency tarballs as GitHub releases".
I'll show how to use GitHub for dependency tarballs as an external #Gentoo#contributor, such as a proxied maintainer, a GURU committer, or an overlay #maintainer.
I use this approach to package #opensource#Golang software, and it can be applied to other similar situations, or even automated through local scripts or GitHub Actions.
What kind of trust does a project #maintainer need to have in a new co-maintainer? To get better at #opensource#sustainability, we need to improve at recruiting, training, & promoting new leaders.
I cover attributes to check for.
I mine 4 comparable situations for assessment ideas, & explain how to reduce how much trust you NEED to give by promoting someone.
In my talks and discussions about the role of Open Source maintainers, I usually list a number of reasons why maintainers might quit or otherwise reduce their involvement.
"The Russian army destroyed my house" hasn't been on that list yet 😐 🇺🇦
If you are contributing to Free and Libre Software (as developer, designer, UI/UX researcher, translator, and other roles included), how much of your time spent in FLOSS do you dedicate to a project in the long term?
(Also read: Are you rather a fly-by contributor or long-term maintainer)
You make the leap of faith that this stranger will stick around and be responsive for weeks/months of intermittent communication.
Or you don't. You ignore the patch, or leave it for a "later" that never comes. Or you explicitly say it's not good enough & you'd rather do it yourself, & close the thread.
I will say though that every time I report a bug, and get a "not our problem" response, it makes it less and less likely that I keep reporting bugs. Yes, technically, the qtile thing was not a qtile problem. But as a non-developer, it's hard to always know who to go to. It usually makes the most sense to go to the developer of the thing itself. It's not great to get "not our problem" when you took the effort to do the thing that devs always say they want you to do.
It is really off-putting whenever some #maintainer (whether the project is #OpenSource or not) acts like they want to pass the baton to another lawn altogether or wontdo list, instead of contributing to solving the problem. Well, dear #developer, if you have nothing to add, then why even bother with the ticket? #Development is not about seeing those numbers in the top bar decrease and increase. 🙄
New blog post on user support frustration, its causes, and how we could build the "infrastructure of equanimity" in #opensource, including ideas for potential cross-project tools & practices.
Shout-outs to @davidism, Heidi Waterhouse, @offby1, @jacob, Nicole Harris, @bernard, + @georgia for work & conversations that I built on in this piece.
What specific mindset shifts can help #maintainers retain equanimity? I think each #maintainer needs to consider power & economics, develop their own analysis of what they & users owe to each other, AND reflect on their own needs/personality. Then, they ought to use those assessments to define their limits + publicly set expectations.
Collective supports:
A shared blocklist, or at least a warning flag
Boilerplate policies
Flagging old resources as old
Shared UX research efforts
I was invited to join #GitHub's private Maintainer Community and participated in their "Personal ecology for open source maintainers: self-care, and avoiding burnout" workshop, together with ~40 fellow maintainers.
The result of our discussion is a new Open Source Guide published about Maintaining Balance for Open Source Maintainers:
At #PyConUS2023, @davidism facilitated an open space discussion of "maintainer #burnout, how to survive it, and maybe how to prevent it." Our notes, my analysis, and useful links in a new blog post:
People who package Go software for #Gentoo probably noticed the deprecation of EGO_SUM in favor of dependency tarballs.
While the mailing lists and IRC channels provide plenty of opportunity to discuss how to supply dependencies for Go software, here I share a way to use GitHub releases to host dependency tarballs as an external Gentoo contributor, like proxied maintainer, GURU contributor, or overlay #maintainer:
The #PyConUS2023 open space on #maintainer burnout: ~20 people sharing experiences and tips. I'm writing a longer blog post with thoughts and resources, but here's the heart of my advice: