Mastodawn

unfinished thought: it would be quite good to have something like the Toolforge Abandoned Tool policy (https://wikitech.wikimedia.org/wiki/Help:Toolforge/Abandoned_tool_policy) for non-tool Wikimedia code, such as libraries (e.g. #m3api) or applications (e.g. Pattypan?)

this could be a step towards “Off-the-shelf governance models for small FOSS projects” (@pintoch, https://antonin.delpeuch.eu/posts/off-the-shelf-governance-models-for-small-foss-projects/) – if a codebase opts into it (README.md?), there would be an established process for adopting it if the maintainer goes inactive

#Wikimedia #Toolforge

Help:Toolforge/Abandoned tool policy - Wikitech

Show thread

taavj Mar 5

@LucasWerkmeister @pintoch hmm. not sure if I want the maintainership of some code I depend and trust on being forcibly passed to someone the original maintainers (who I had explicitely trusted by using the library) hadn't explicitely supported, without some explicit action on my end (like updating the package name) on my end to choose to trust it

Show thread

Lucas Werkmeister Mar 5

@taavi I'll have to turn this over in my head some more, but I'm puzzled to hear this from a Debian Developer… while there are of course differences (such as a more closed, trusted pool of developers), doesn't Debian also have something that fits your description? (from a quick look through the docs, Package Salvaging would seem to fit? https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging)

5. Managing Packages – developers-reference 14.4 documentation

Show thread

Lucas Werkmeister

@taavi anyway, just spitballing before I go to sleep ;) but at least in the more limited context of libraries in ecosystems that use semver, I could imagine mitigating this concern by requiring that the first new release post-adoption must be a new major version which mentions the adoption in the release notes, thus giving users of the library an opportunity to notice the maintainership change?