Proposal: Expanding the CLC

[John Ericson]

Yeah I strongly agree with the sentiments here, and the concrete 
measures. Thank you, Emily, for proposing them.

I assume some people will be worried about undermining the prerogative 
of individual maintainers. My view is this *not* a good reason to "hold 
the CLC back". A bit off topic, but In the long term, I am optimistic 
for technical solutions to make dealing with libraries and versions, 
alternative ecosystems, etc. easier. Basically I want it all---both 
collaborative ownership and authorship, and healthy decentralized 
experimentation---and I think that's possible.

John

On 2/12/21 1:46 AM, Julian Ospald wrote:
> Hi,
>
> my opinion is that we should develop a zero tolerance towards 
> unresponsive maintainership.
>
> Contributors shouldn't have to escalate on the ML and shouldn't have 
> to request package takeovers. These things are awkward and require 
> more dedication than necessary to be a valuable co-maintainer.
>
> The CLC should proactively scan for popular packages that require new 
> maintainer juice, contact the current maintainers and call for help on 
> the ML (whether core/boot/something-else doesn't really matter to 
> me... redefine the CLC competencies if you must).
>
> I've had many PRs over the years that took 6-12 months for a response. 
> This is not an acceptable response time.
>
> Cheers,
> Julian
>
> On February 11, 2021 11:54:19 PM UTC, Emily Pillmore 
> <emilypi at cohomolo.gy> wrote:
>
>     Hi All,
>
>     Over the past year, two things have become increasingly clear to
>     me as I've carried out my CLC duties:
>
>
>     1. The CLC is under-resourced. This is evidenced by the fact that
>     several maintainers who are not CLC members have been forced to
>     step up to help take on some of the maintenance burden for many of
>     the CLC libraries. Namely, `vector`, `bytestring`, `random`,
>     `unix`, and more. The current CLC head count is not enough to
>     dedicate at least one maintainer per package, which is leading to
>     us all being spread thin, and the less-loved packages are falling
>     into disrepair as a result. Couple this with the fact that roughly
>     half the CLC do not have these packages actively within their
>     maintenance cycles, and we arrive at the current problem.
>
>     2. The current set of "core" libraries does not cover what is
>     generally considered "core" in the community. From now on, I'll
>     refer to "core" packages as "boot" packages, and identify core
>     packages to be those that are have proven to be incredibly popular
>     tools for building things in Haskell. For example `zlib`,
>     `parsec`, `regex-base`, `regex-posix`, `network`, etc. In
>     particular, if any of these core packages saw their current
>     authors disappear, or incapacitated in any sense, it would
>     seriously harm the Haskell ecosystem. `cabal-install`, for
>     example, requires several of those packages as upstream
>     dependencies. Currently, we are dealing with this nightmare
>     situation where work is stalled across many packages due to a
>     particular set of maintainers being very difficult to reach, one
>     of whom having disappeared completely for all maintenance intents
>     and purposes.
>
>     Ergo, we have a problem. Thankfully, many people have stepped up
>     showing renewed interest in maintaining such packages with the
>     latest crop of CLC folks, and this poses an interesting opportunity.
>
>     My proposal is this:
>
>     1. We expand the CLC from 9 members to 22 members such that we
>     have at least 1 CLC maintainer per boot package. There are a large
>     number of fantastic candidates already available, who would be
>     perfect for the role. In fact, many of the candidates whom we
>     would ask are already maintaining these packages. In particular,
>     Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic
>     Steinitz, Alexey Khuedyakov are already serving within this role
>     (and thank you for it!). Andreas Abel has also offered to help
>     take on one of the core packages.
>
>     2. We consider a dedicated "Haskell Action Team" (name and idea
>     courtesy of Carter Schonwald) to oversee packages in the Haskell
>     github repo that can act as supplementary maintainers for many of
>     the core packages contained therein. Currently, there are many in
>     need of help. `zlib` comes to mind, which is currently blocking
>     `bytestring-0.11` migration work due to having no available
>     maintainer with the permissions to do a release. This, in turn, is
>     stalling `cabal-install`. Short of taking over the package, we
>     would have to ask for an emergency Hackage release if the neither
>     maintainer shows up to do it in a reasonable time frame.
>
>     This is just one step towards helping ease the burden of
>     maintenance of so-called core and boot packages. I hope you agree
>     that this is a good idea, and if we get enough thumbs up, then
>     Chessai and I will draw up the necessary changes to the CLC remit
>     and we'll get started!
>
>     Cheers,
>     Emily
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210213/66f8735b/attachment.html>