New CLC proposal process

[Andrew Lelechenko]

Julian, I would like to apologise for the treatment your efforts have received. This is not an appropriate behaviour towards open-source contributions. I believe that AFPP is an extremely important development towards better Haskell.

The thing is that a desired shape of CLC, capable of guiding and pushing wide ecosystem changes, has never existed in the first place. CLC was formed in 2013; how many significant shifts to core libraries happened since then? I remember only one: `random-1.2`, and even that was mostly backwards compatible, similar in this quality to the recent `text-2.0`. Core libraries were generally meant to stay in a stable, maintenance-only state, not needing much attention. 

I'd love to see the current CLC growing into such ecosystem force, but we are not there yet. We need to regain community’s trust and confidence, lost over the course of years. That’s why dealing with `base` backlog is the first order of business for now.

> where do I go? Who do I ask?

In theory you should go to maintainer(s) of relevant libraries and discuss your proposal with them first. If they ignore or neglect it, you can raise an issue with CLC, which will mediate or resolve the matter other way. If they do not have a strong opinion, they can consult CLC for a wider perspective and approval. 

But a dire state of current affairs is that `filepath` is without maintainer, so the very first step is impossible. We are blocked until we find a new active maintainer.

Best regards,
Andrew

> On 3 Nov 2021, at 12:47, Julian Ospald <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
> [1] https://github.com/hasufell/abstract-filepath/issues/10#issuecomment-957404954
> [2] 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
> [4] https://mail.haskell.org/pipermail/libraries/2021-August/031427.html
> [5] 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
> [7] https://github.com/haskell/text/blob/7a492ecff429748386dbde7da0db45a0bfb8dcda/text.cabal#L44