Proposal: Expanding the CLC

Fri Feb 12 00:32:13 UTC 2021

I guess my main point is that this mailing list reflects and via predating
clc, defines what clc is for.

And rather than scope creep a single responsibility, articulating that need
and facilitating is as a distinct entity is valuable.  My idea with HAT is
like a modern volunteer organizing touch point of Ye olde Haskell janitors,
with each year some different set of folks who were active the previous
year as new leadership/organizing touch points for helping facilitate
active contributors the subsequent year.  Designing for churn to stay fresh
as a different take than how we’ve done many of these entity’s for Haskell.

Actual Maintainer-ship  responsibility should not be via Hat (at least as I
envision it), though supporting and empowering active contributors may
happily result in some of them being contrib i/ comaintainer.

Equally important: library maintainers being responsive about bug fixes is
important. Just as important is allowing them agency to evolve the Libs
they maintain.  I do worry that some Libs that fall under clc atm / as of
the spring are likely to never have serious evolution / improvement. But
that’s a different issue.

On Thu, Feb 11, 2021 at 7:13 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> These are good points
>
> I think this is actually 3-5  points:
>
>
> CLC  related
> 1) clc authority is strictly about leadership for helping make design
> decisions for base the package
>
> 2) clc is meant to be a fallback to ensure that there’s backup continuity
> for maintainership of ghc boot libraries and a design aid for Haskell
> library authors who are the current maintainers.
>
> But as long as the current maintainership is reachable for communication,
> the maintainer has final authority.
> — the clc violated this in spring 2020, while there were car burnings in
> the neighborhood of the maintainer in question . Bad taste.
>
> 3) peripherically clc via base maintainership is the design authority for
> the library section of the Haskell standard.
>
> —- point being: if you’re not contributing to design decisions for base.
>  you shouldn’t be on the clc.  If you are, then you should perhaps be on
> clc.  The current makeup of the clc does not reflect that.
>
> — further more , growing clc should be a reflection of contributors being
> recognized for their design/hackery contribs
>
> HAT related
> 4) the idea/goal of hat: empowering and supporting active contributors
> while not saddling them with official commitments. Rather, HAT is about
> somone (myself initially), acting as a shield to support current active
> contributors to enable them to act with greater confidence. I like to think
>  I helped enable that with some of the folks emily mentioned, especially
> Simon jakobi, viktor and Andrew L.
>
> On Thu, Feb 11, 2021 at 6:54 PM 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/20210211/d51e210a/attachment.html>