Lucas Werkmeister

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

Mar 4 at 11:31pmWeb
Show threadLucas WerkmeisterMar 4
(the technical side of this would get tricky, because whichever committee is tasked with managing the adoption process would need to be empowered to manage access not just to the code base – ideally Wikimedia GitLab, likely oftentimes GitHub – but also to any of a number of channels where the library/application/whatever may be distributed, i.e. add the new co-maintainer on: npm? PyPI? NuGet? etc.)
Show threadJan AinaliMar 5
@LucasWerkmeister I like the idea. Tricky or not, it could provide some pathways forward in some cases in the future. Just agreeing on when such tools can be considered abandoned can give clarity.
Show threadAntiCompositeMar 4
@LucasWerkmeister ideally we'd help people get co-maintainers before they stop maintaining something, but that's been harder, especially for newcomers who can't just assign someone. So a designated maintcom account that could be given maintainer access for emergencies etc would be good. Ideally we'd be moving the important stuff to the WMF GitLab, but not everyone wants to do that so we'd have to meet people where they are. Or we'd have to try to rationalize the several different GH orgs.
Show threadtaavjMar 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 threadLucas WerkmeisterMar 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 threadLucas WerkmeisterMar 5
@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?
Show threadtaavjMar 5
@LucasWerkmeister well, any DDs practically have the ability to run arbitrary code on my laptop right now, regardless of whether they go through that social process or not. but any arbitrary Phabricator users who show up to want to take over some abandoned thing do not. the abandoned tool policy explicitely has provisions to not pass on secrets to the new person just showed up, for these reasons