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

Mon Apr 5 22:04:27 UTC 2021

I think this is a fine framework for specifying what should happen with a package. Even better would be if e.g. Hackage had a field where you could specify this, so that it could be easily found by the Hackage maintainers. But maybe you don't need to interact with the Hackage maintainers because your backup maintainers already have commit rights? A truly wonderful solution would include a feature where e.g. Hackage emailed all backup maintainers for all packages once per year asking them to reconfirm their willingness to serve. And having this as a field in Hackage would help to encourage all packages to follow suit and would be a loud signal to potential adopters that you have anticipated their needs into the future.

But it's best to maybe start small. Here's a possible way to get more widespread adoption:
 - Put this in your own packages' repos, perhaps in a living-will.md
 - Create a little badge icon, and display it in your README with a link to living-will.md.
 - Convince a few friends to do the same. Make sure they display the badge.
 - We programmers like badges. Others will want the badge, too. They will follow suit.
 - Demand for this feature on Hackage will grow. Hackage will implement.
 - Sleep well, knowing you have bettered the world.

Richard

> On Apr 5, 2021, at 8:03 AM, Tom Ellis <tom-lists-haskell-cafe-2017 at 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.