<div dir="auto">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 </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 13, 2021 at 3:03 PM John Ericson <john.ericson@obsidian.systems> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div>
<p>Yeah I strongly agree with the sentiments here, and the concrete
measures. Thank you, Emily, for proposing them.</p>
<p>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.</p></div><div>
<p>John<br>
</p>
<div>On 2/12/21 1:46 AM, Julian Ospald
wrote:<br>
</div>
<blockquote type="cite">
Hi,<br>
<br>
my opinion is that we should develop a zero tolerance towards
unresponsive maintainership.<br>
<br>
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.<br>
<br>
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).<br>
<br>
I've had many PRs over the years that took 6-12 months for a
response. This is not an acceptable response time.<br>
<br>
Cheers,<br>
Julian<br>
<br>
<div class="gmail_quote">On February 11, 2021 11:54:19 PM UTC,
Emily Pillmore <a href="mailto:emilypi@cohomolo.gy" target="_blank"><emilypi@cohomolo.gy></a> wrote:
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div>
<div>
<div>Hi All,<br>
</div>
<div><br>
</div>
<div>Over the past year, two things have become
increasingly clear to me as I've carried out my CLC
duties:<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>My proposal is this:<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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!<br>
</div>
<div><br>
</div>
<div>Cheers,<br>
</div>
<div>Emily<br>
</div>
</div>
<div>
<div style="display:none;border:0px;width:0px;height:0px;overflow:hidden"><img src="https://r.superhuman.com/U7KH74R7u-V9iyQnGsldIpSxcbRAMT2Jo_DcUpzixrkPj5PwLKOkDXILUETmGzIi8rjC_ejMHs7kzXTAum8_7pq2tJWtULkJLs2q5QcZdYr9HlorvLsgEa6B3IETytSDpo6YZt0_MrVTWDWIB6LM0v8Ig4cWQf9jkOQY9u8z58_l1jMTpfXCpAw.gif" alt=" " style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden;" width="1" height="0"></div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre style="font-family:monospace">_______________________________________________
Libraries mailing list
<a href="mailto:Libraries@haskell.org" target="_blank" style="font-family:monospace">Libraries@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank" style="font-family:monospace">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>