Re: New CLC proposal process

`text` (and `text-icu`) were formally transferred to CLC by Bryan in March 2021. README says that CLC __as a collective body__ does not maintain core libs. This does not prohibit its individual members to be maintainers, and they are indeed encouraged to do so. Best regards, Andrew

On 3 Nov 2021, at 14:00, Carter Schonwald wrote:

There’s also the claim of forward looking eminent domain rights, when as best I can determine, what’s happened is maintainership of text fell into new volunteers who work with/are currently clc.

This is also at tension with the claim of not being maintainers of core Libs ….

On Wed, Nov 3, 2021 at 8:48 AM Julian Ospald mailto:hasufell@posteo.de> wrote: On Wed, Nov 03, 2021 at 09:17:38AM +0000, Simon Peyton Jones wrote:

...

| These core libraries are the first thing everyone getting into haskell | is going to interact with. Having a fragmented set of maintainers | without a body that connects them sounds like a terrible idea.

I'm not much involved in these changes, but reading [1] it says

As a collective entity CLC owns, but does not maintain so-called Core Libraries

So it sounds as if the CLC will continue to play the role of "the body that connects them", while still giving autonomy for the individual core libraries themselves to their respective maintainers. That sounds OK to me, doesn't it?

I'm confused. So I'll reiterate my position.

I've been working the past 7 months [0][1] on a proposal that hasn't moved forward since 2015 [2].

I've posted it on discourse [3], on this mailing list [4] and have contacted the CLC several times in private, of which there was no useful feedback, except "yeah, go ahead".

In this very thread I was told that CLCs responsibility is base only and I was offered no official help from the CLC, except an offer "in personal capacity" (which I appreciate, btw) [5]. This could be perceived as "yeah, not our problem, try somewhere else maybe", even if it wasn't meant that way.

I'm sorry, but this isn't good enough. A body that has existed for this long can't just re-define its responsibilities, because they lack time or engagement. Offloading core libraries issues to the Haskell Foundation is in no way a sensible option. I appreciate all the work the HF has done, but a healthy community doesn't exist of just one body that manages everything. CLC has always had a very strong focus on technical aptitude and had very little do do with politics. There's a reason for that. Core libraries are a special matter and can't just be left to individual maintainers. A body helping governing those should have strong independence, so that it can say "yes" or "no" to anyone and anything, without conflict of interest.

So after I've been neglected here, where do I go? Who do I ask? I'm afraid this is a big problem. If we can't manage changes across core libraries, then our library ecosystem is defunct at its very core.

So far, the only recent changes to core libraries was a proposal that merely changed internal API and was authored by the maintainer of the library itself [6][7]. I say "merely" not because it was little work (it wasn't), but because changes to internal API are less controversial.

However, this is no proof that this community can manage changes outside of its circle of maintainers.

I'm aware most people here are volunteers, but so am I. My concern here is that we're reinforcing subtle cliquesque behavior and the only people who can move anything forward are those with the right connections.

CLC is the body to provide these connections to anyone. If CLC can't do this, then I consider this reboot a failure.

Cheers, Julian

--

[0] https://github.com/hasufell/abstract-filepath https://github.com/hasufell/abstract-filepath [1] https://github.com/hasufell/abstract-filepath/issues/10#issuecomment-9574049... https://github.com/hasufell/abstract-filepath/issues/10#issuecomment-9574049... [2] https://mail.haskell.org/pipermail/libraries/2015-June/025852.html https://mail.haskell.org/pipermail/libraries/2015-June/025852.html [3] https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp... https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp... [4] https://mail.haskell.org/pipermail/libraries/2021-August/031427.html https://mail.haskell.org/pipermail/libraries/2021-August/031427.html [5] https://mail.haskell.org/pipermail/libraries/2021-October/031512.html https://mail.haskell.org/pipermail/libraries/2021-October/031512.html [6] https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/acce... https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/acce... [7] https://github.com/haskell/text/blob/7a492ecff429748386dbde7da0db45a0bfb8dcd... https://github.com/haskell/text/blob/7a492ecff429748386dbde7da0db45a0bfb8dcd... _______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries