New CLC proposal process

[Andrew Lelechenko]

`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 <carter.schonwald at gmail.com> 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 <hasufell at posteo.de <mailto:hasufell at 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-957404954 <https://github.com/hasufell/abstract-filepath/issues/10#issuecomment-957404954>
> [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-in-user-space/2344 <https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space/2344>
> [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/accepted/002-text-utf-default.md#people <https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/accepted/002-text-utf-default.md#people>
> [7] https://github.com/haskell/text/blob/7a492ecff429748386dbde7da0db45a0bfb8dcda/text.cabal#L44 <https://github.com/haskell/text/blob/7a492ecff429748386dbde7da0db45a0bfb8dcda/text.cabal#L44>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211111/bd187e0a/attachment.html>