Re: Proposal: Expanding the CLC

Absolutely. I think there could very well be a platform that focuses solely on authorship. This could be made easier by enforcing package names to contain the authors username and then relying on package-qualified imports or something. Just random thoughts.

But yeah, hackage is not that. It already contains various means to deal with maintainership that exceeds authorship.

There's a good counter-argument to my proposal though, namely that it may undermine a users trust in a package, which may be based on the authors quality standards and their attitude. I agree it is an argument, but I also believe a body like the CLC has sufficient competency to make up for this. And it's also a reminder to every maintainer: make sure you have co-maintainers you trust, such that this will never become a problem.

On February 13, 2021 8:03:04 PM UTC, John Ericson <[email protected]> wrote:
>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 
>> <[email protected]> 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
>> [email protected]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries