Back

@pintoch I think the idea is interesting!

@Ash_Crow thanks! I am especially interested to try it out within the #wikimedia tools ecosystem, where the human sustainability question is a rather well identified problem…

@pintoch trying to identify the different governance models in place in the Wikimedia world (for single-dev things, so not counting Mediawiki itself and other Big Stuff on Gerrit/Phorge):

@pintoch

- official gadgets follow the wiki way you mention, with a pool of interface editors who can and will edit any gadget that needs editing, and simple talk pages where users can ask for features or report bugs. The pool of interface editors can be very small on certain Wikimedia projects though.

@pintoch

- user-space gadgets follow two non-explicit policies: Just fork it for users who can, BDFL for users who can't...

@pintoch wiki templates/Lua modules are another example of the wiki way, and are not restricted to specific user rights unless the remplate is largely used.

@pintoch Toolforge tools have an explicit "BDFL until abandoned" policy: a single author, or a small group of authors, is in charge, but if they stop being active, someone else can request to take over the tool.

@Ash_Crow that's such a great analysis! I never thought about it in such clear terms, and it feels to me that just doing that is already solving a big part of the problem :)

@pintoch

Looking out of Wikimedia, I guess https://peps.python.org/pep-0541/ also makes Python libraries on Pypi have the "BDFL until abandoned" policy.

And Jazzband https://jazzband.co/ is an attempt at establishing a wiki-style governance model over previously abandoned Python projects.

@pintoch @Ash_Crow Jazzband is a great idea, but it failed in its own governance model. https://github.com/jazzband/help/issues/196

@bd808 @pintoch that's why I said attempt. There shouldn't be a lone roadie...

@pintoch @ainali back when I was an active maintainer of the @tldr_pages project, I helped develop a set of guidelines (and even a CLA) that were not explicitly meant to be reused as templates, but did have a focus on simplicity/accessibility, aiming to make the governance of the project permeable and self-sustaining, with a semi-automated (manual, but based on clear criteria) process of onboarding occasional contributors into regular contributors and into maintainers. Relevant links follow:

@pintoch @ainali @tldr_pages

- Main governance document: https://github.com/tldr-pages/tldr/blob/main/GOVERNANCE.md
- Process for role transitions: https://github.com/tldr-pages/tldr/blob/main/COMMUNITY-ROLES.md
- Guide for maintainers: https://github.com/tldr-pages/tldr/blob/main/contributing-guides%2Fmaintainers-guide.md
- The CLA (must be a gist, unfortunately): https://gist.github.com/waldyrious/e50feec13683e565769fbd58ce503d4e

@pintoch @ainali @tldr_pages I believe I may not have shared this with you yet, but I have a (very WIP) document where I've been collecting notes about FOSS governance for a few years now: https://docs.google.com/document/d/1O02JPpwTvV5Dd-eL62Hk2bdjipGYZncFMdEnMEZ8hA8/edit. For this particular discussion, you may be interested primarily in the "Document templates" section.

@pintoch @ainali @tldr_pages responding to the blog post, I believe the main ingredients of a sustainable and truly open governance model includes two things: (1) clear documentation of the process for role transition (including retirement or semi-retirement) and of the expectations for each role in the regular maintenance of the project; and (2) automations that either implement governance processes or facilitate them: e.g. bots or permission granting mechanisms a la StackOverflow.

@pintoch @ainali @tldr_pages template documents can help with (1) and stuff like probot, stale-bot, or custom automations (can GitHub Actions modify membership and permissions in a project/org?) can help with (2). But I totally agree that platform defaults play a huge role in making these the rule rather than the exception. Toolforge and Forgejo definitely sound like fertile ground to try out ways to encourage these more open governance mechanisms at the platform level.

@waldyrious @pintoch @ainali I remember this being implemented. It's worked very well indeed! Thanks so much for drafting & implementing it, @waldyrious!

--Posted by @sbrl

@tldr_pages the TLDR governance and community roles document are really great. Precise but still concise. It looks like an excellent basis for a generic model. @waldyrious 's Google doc is a gold mine! Such impressive surveying work!

@waldyrious concerning automated permission granting by bots / GitHub Actions, I was also hoping for that some months ago but changed my mind recently:
* it would require giving admin permissions to a bot or the CI, which feels dangerous
* being welcomed by a bot feels weird to me. Being invited to a role by a human is more rewarding.
[1/n]

@waldyrious
* the scenarios in which such systems could salvage a maintainer-less project (by automatically promoting a contributor to an owner) feel quite unlikely to me (what about credentials for package repositories, domains?)
* it's good when governance systems are implemented by the humans involved (even if it involves some mundane actions that could be automated away) because it helps keep the theory and practice consistent (a point @enfascination mademore convincingly in Metagov slack)

@waldyrious @enfascination that being said, I do think automating some things can be useful, more in the form of reminders (should this person be invited to this role? has this person become inactive and should be removed?), to reduce the need for team members to take initiatives in this area.

@waldyrious @enfascination In @kanthaus for instance, I find it very useful that we get regular reminders about removing long-term absent people. It's difficult for me to spontenously take the initiative to demote people that I trust and appreciate, but it's needed if we want our list of Volunteers and Members to reflect who feels responsible for the house. (See the "Evaluations and check-ins" in https://kanthaus.online/de/governance/minutes/2024-03-25_come for an example)

@pintoch @enfascination @kanthaus those are all good points. Let me address a few:

1) StackOverflow has shown that an auto-promotion mechanism (save from moderators, who are explicitly elected) can work without being too cold. Of course human interaction is better, but in pragmatic terms, a system that scales regardless of the current members' energy and time availability is preferable to a warmer system that is more vulnerable to failure. 1/8

@pintoch @enfascination @kanthaus indeed, I've come across several projects whose author proclaimed to want to give out permissions generously but was no longer around when volunteers eventually showed up wanting to help.

2) I agree that giving bots admin permissions can be dangerous, but that's an argument for setting up those mechanisms at the platform level. That said, experimenting with bots in lower-risk projects may be necessary to prove that the principle works. 2/8

@pintoch @enfascination @kanthaus plus, a transparent configuration of what the bot does (e.g. probot-settings allows managing repo settings via a `.github/config.yml` file, making them version-controlled, publicly visible, and edited transparently with pull requests) can help. I quite like the bots used in gitlab's own repos (i.e. the source code of girls itself) whose messages always include a link to the source code of the bot and an invitation to improve its messaging or behavior. 3/8

@pintoch @enfascination @kanthaus

3) regarding removing permissions, I also am ambivalent about that. Unless the accounts are actually inactive in the platform, I don't think it brings much additional security to remove their extended rights. I get the point about the list of maintainers of a project accurately reflecting those who are actively maintaining it, but that can be done by moving the inactive maintainers to an "emeritus" list or something of the sort. 4/8

@pintoch @enfascination @kanthaus mind you, I have myself volunteered to go through that process with @tldr_pages, where I stepped down as a maintainer and lost the additional access when I realized my availability had been consistently low, but ever since I have now and again bumped into occasions where the extra permissions would have allowed me to give a helping hand (or address minor issues) and I was prevented from doing so. 5/8

@pintoch @enfascination @kanthaus @tldr_pages this stance is greatly informed by my experience as an admin on English and Portuguese Wikipedias, and Wikimedia Commons. On the latter two I was demoted due to "inactivity" (not performing sufficient administrative actions) even though I remained an active editor and occasionally needed the extra rights. The demotion left a sour taste in my mouth to be honest (but maybe it was because it was implemented in a rigid way with no room for nuance) 6/8

@pintoch @enfascination @kanthaus @tldr_pages I read somewhere (maybe I should dig up the actual quotes) that the English Wikipedia's admin policy rests on a philosophy of granting access as a way to remove barriers for future participation, not so much as a recognition of past work done. This approach thus encourages both liberal promotion (countering the expectations is the "1% Rule") and conservative demotion, to reuse the wording of the Postel's law, aka the robustness principle. 7/8

@pintoch I agree, but https://codeberg.org/mergiraf/mergiraf/src/branch/main/GOVERNANCE.md feels very much like a contract to me. How does one bring it alive?

@nemobis I imagine something a bit like the #creativecommons licenses: a simple web page explaining the spirit of the model and how to put it in practice, which goes together with a more detailed document which can be referred to in corner cases.

@pintoch Creative Commons licenses are a good example. They work in 99,999 % of the cases which are uncontroversial. They break down when people actually try to enforce them, because it turns out none of the participants had really understood what they had signed up for. (This is copyright's fault.)

I think we need something else, regular rituals which are actually helpful and a joy to participate in.

@pintoch And by rituals I mean things like...

Welcome committee: approving requests to join.

Graduation: approving forgotten requests to be promoted to a certain group in the repo.

Barn raising: approving a forgotten merge request someone prays for.

Potluck: ??

Code amnesty: ??

Mediation: ??

Jury duty: handling complaints about people after mediation has failed.

A group of 3 is picked by sortition from a pool of volunteers to the task. They decide by consensus. (How to facilitate??)

@giacomo I liked the people. We spent quite some time together! I didn't like the legal instrument.

@giacomo I hope too!

We just need to make sure we don't start from a discussion of copyright licenses because I'm never going to change mind there. ;)