<div dir="auto">I guess my main point is that this mailing list reflects and via predating clc, defines what clc is for.  </div><div dir="auto"><br></div><div dir="auto">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.  </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 11, 2021 at 7:13 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> 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 dir="auto">These are good points</div><div dir="auto"><br></div><div dir="auto">I think this is actually 3-5  points: </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">CLC  related </div><div dir="auto">1) clc authority is strictly about leadership for helping make design decisions for base the package </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">But as long as the current maintainership is reachable for communication, the maintainer has final authority. </div><div dir="auto">— the clc violated this in spring 2020, while there were car burnings in the neighborhood of the maintainer in question . Bad taste. </div><div dir="auto"><br></div><div dir="auto">3) peripherically clc via base maintainership is the design authority for the library section of the Haskell standard.  </div><div dir="auto"><br></div><div dir="auto">—- 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.  </div><div dir="auto"><br></div><div dir="auto">— further more , growing clc should be a reflection of contributors being recognized for their design/hackery contribs </div><div dir="auto"><br></div><div dir="auto">HAT related</div><div dir="auto">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.  </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 11, 2021 at 6:54 PM Emily Pillmore <<a href="mailto:emilypi@cohomolo.gy" target="_blank">emilypi@cohomolo.gy</a>> 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><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=" " width="1" height="0" style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden;"></div><br><div></div></div></div></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>
</blockquote></div></div>