[Haskell-cafe] Designing a "living will" for my packages on Hackage

[Tom Ellis]

# 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