Proposal: Expanding the CLC

Tue Feb 16 13:56:55 UTC 2021

There’s a lot more smart quiet folks who just need the right cheerleading
and guidance out there than you’d expect.  Or any of us can imagine.

The way anyone gets great at stuff starts from somewhere, and we need to
seriously consider and work at making sure the ramp/funnel of participation
and inclusion is as wide as possible. Current Haskell processes are not
really setup to handle continuity and growth of participation as well as we
should aim for.

The entire premise/ point of new efforts like the Haskell foundation is
that we need to genuinely ask: how do we help more folks get great at their
software needs, and facilitate Haskell and or ideas embodied thereof,
empowering more folks over time. And this attitude should be reflected in
how we evolve and improve and maintain core infra tools and libraries.

On Tue, Feb 16, 2021 at 4:04 AM George Wilson <george at wils.online> wrote:

> I would be happy for the CLC to expand, assuming that qualified candidates
> step forward.
> Twenty-two seems rather optimistic to me, since we typically don't see
> many applicants. Perhaps it can be an aspirational goal.
>
> Regarding a "Haskell Action Team", I definitely think more maintainers on
> some core libraries and more active members of the Haskell github
> organisation would help, but I'm not sure we really need another named
> volunteer organisation established within Haskell.  Between the CLC, the
> Hackage trustees, the Haskell.org Committee, the GHC Steering Committee,
> the Haskell Prime Committee (if it gets going again), and now the
> Foundation, we really do have a lot of those already. I bet I have even
> forgotten at least one!
> To attempt to form this new group, on top of expanding the CLC to
> twenty-two, would surely involve a significant overlap between the groups.
> Otherwise you'd have to conjure a lot more trusted, highly-advanced
> Haskellers with free time than I think exist.
>
> Cheers,
> George
>
> On Tue, 16 Feb 2021 at 04:11, John Ericson <john.ericson at obsidian.systems>
> wrote:
>
>> Carter,
>>
>> It's not exactly clear to me where your two proposals differ? It seems
>> like Emily said "bigger CLC" with HAT, while you are saying a separate org,
>> perhaps with the CLC inside the HAT? I'm guessing the idea there is to make
>> the degree of control inversely vary with the number of libraries in the
>> purview?
>>
>> > 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.
>>
>> Yes I would like to get into that at some point too. (Pithily put, my
>> view is chop up each library until its contents are uncontroversial.) This
>> is what makes me less concerned about the difference between a bigger CLC
>> and rings of orgs.
>>
>> John
>> On 2/13/21 7:01 PM, Carter Schonwald wrote:
>>
>> I agree with your articulated long term goal points, I just worry that
>> we’re not investing in the right structures of organization to support
>> that.  I’m more than happy to be wrong though
>>
>> On Sat, Feb 13, 2021 at 3:03 PM John Ericson
>> <john.ericson at obsidian.systems> <john.ericson at obsidian.systems> 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
>>> <emilypi at cohomolo.gy> <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 listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> 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/20210216/02ea9575/attachment.html>