I think having your personal policy, however phrased, in the readme or a linked document about maintainership / nmu bug fix stance life cycle is a great idea. I should note that this is actually articulating the *governance* of your project and there can’t really be a one size fit all template. Like, no commits for n months may be fine for a research effort or a stable lib that has no bugs, but is very different when long standing bugs that are reproducible and have real user impact around correctness / performance / new compiler compat. Note that what I mean is that ultimately: you are the current owner of your project. Governance here actually means you are explicitly publishing a pseudo (in that we arent lawyers here mostly ) legal document articulating a) what conditions you pre authorize an non maintainer update and or b) under what conditions you either designate certain folks should become designated co maintainers with various fall backs c) under what conditions you transfer associated intellectual property to a new entity or human for stewardship of your project This can get pretty thorny or nuanced , hence why various large enough prjects get a foundation organized around them often, but is never a bad thing to think about if you’re concerned. And def something we as a community should respect any such documents at least when they’re valid (, like having Alan Turing as your successor maintainer wouldn’t make sense or similar manner of stuff ) On Mon, Apr 5, 2021 at 8:05 AM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:

# Introduction

Over the past few weeks I've seen several instances of difficulty caused by unavailable or unknown package maintainers. I want to minimise the risk that difficulties arise for users of my packages should I ever become unavailable or uncontactable.

I'd like to brainstorm policies for achieving this. My immediate goal is to find a suitable policy to apply to my own packages but I also have an indirect goal that the policy be suitable and appealing for others to apply to their packages on a voluntary basis.

# What already exists?

## My packages already have backup maintainers

I am already fortunate enough to have backup maintainers who have agreed to make bugfixes and dependency version bumps should I become unreachable:

https://github.com/tomjaguarpaw/haskell-opaleye#backup-maintainers

Two caveats:

* Bugfixes and dependency version bumps are really the absolute minimum needed to ensure continuity of service. Much more is needed for the general health and reliability of a package.

* It has been a long time since I contacted these maintainers and asked for their help in this matter. Perhaps if they were called upon now they would no longer have the time to fulfil this role. Perhaps I should ask the backup maintainers every 12 months whether they are willing to continue in the role. If not then that would give me the impetus to find other backup maintainers.

## Do established policies like this already exist?

Perhaps effective backup maintainer policies already exist in the Haskell community or in other language communities? Does anyone know? I would be grateful to find out.

# A simple proposal

I'd like to propose something simple that avoids anything too legalistic or requires multilateral cooperation. For example, if I had three backup X, Y and Z, I could do the following:

* Add these paragraphs to the README

In the event that the maintainer has been unavailable and uncontactable for _three months_ then X is entitled to claim ownership of the package.

In the event that the maintainer has been unavailable and uncontactable for _four months_ then Y is entitled to claim ownership of the package.

In the event that the maintainer has been unavailable and uncontactable for _five months_ then Z is entitled to claim ownership of the package.

"The maintainer has been unavailable and uncontactable" means that the maintainer has not made any commits to the repository nor has been contactable by email [or precise other conditions to be determined].

[Once a backup maintainer has claimed ownership they are entitled to do essentially whatever they like with the package, though I would choose them responsibly so that they continue maintaining the package in a sensible way!]

* Give the backup maintainers write access to the package git repository and to the package Hackage entry, effective immediately

I would choose the backup maintainers carefully so that I trust them not to take drastic actions with the package unless and until the conditions stated in the README are met.

* Clarify with the backup maintainers every year that they are still willing to step in in case I become unavailable.

If not I'll find replacements.

## Questions about the simple proposal

* "Isn't this just the standard practice of having multiple maintainers?"

Basically yes, but with the added benefit that the inheritance and ownership procedure is defined clearly. Hopefully that reassures users and developers about the future of the package.

* "After 4 months have elapsed what stops X and Y trying to claim ownership at the same time?"

Well, not really anything. The first to claim it gets it. But after three months have elapsed I suggest that X take ownership and change the policy, replacing her name with mine. I hope she also deems Y and Z to be good backup maintainers and keeps them in place!

* "How many backup maintainers should there be?"

I suppose that depends on the package. For my packages I'd probably like two or three. Having only one backup maintainer doesn't set my mind at ease. Four seems a bit too much!

* "How long should elapse before claiming ownership is permitted?"

Again that depends on the package. For my packages three months of my absence seems reasonable, plus one month per additional backup maintainer to give each a reasonable time to claim the package.

## What do you think?

What do people think? Will this simple policy achieve my goal of achieving a smooth transfer of maintainership if I become available? Are there any caveats that make the policy unworkable or undesirable? Is there something about it that would make others averse to apply it to their packages? Is there some easy way to make it better?

Cheers,

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.