As https://github.com/haskell/core-libraries-committee/blob/main/README.md https://github.com/haskell/core-libraries-committee/blob/main/README.md says, CLC owns, but does not maintain core libraries as long as they are kept in order by appointed maintainers. If you find a core library abandoned and neglected, raise an issue with CLC. Otherwise proposals affecting core libraries should be discussed with respective maintainers first. They can seek CLC opinion on controversial changes, but are not obliged to. I suppose HF Tech Track could be a helpful body to ask a non-binding opinion on changes with a wider scope. Best regards, Andrew

On 31 Oct 2021, at 00:08, Julian Ospald wrote:

Do I understand correctly that the CLC only governs base now?

If not, where does one raise other issues that potentially affect core libraries?

On October 30, 2021 8:13:18 PM UTC, Andrew Lelechenko wrote: I'm happy to announce that Core Libraries Committee has completed post-election reboot and now has a new home at https://github.com/haskell/core-libraries-committee https://github.com/haskell/core-libraries-committee and a new GitHub-based process: https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md.

From now on proposals to change base should be raised as GitHub issues instead of emails to libraries@.

Best regards, Andrew

1. On contrary, we narrowed CLC from 9 to 6 members to make it more manageable. 2. CLC was incapable to deal with wider ecosystem issues for years. It is better not to nourish false hopes. I believe in “Make each committee do one thing well”. CLC’s primary and undivided responsibility is `base` and, as witnessed by a huge backlog, even this single thing was handled below expectations. It’s not like we are in a good position to accept additional, wider responsibilities. Remember that “core libraries” is an abstract moniker without much consistency: e. g., before very recent `text` was not core, and it includes `mtl`, but not `transformers`, and does not include `containers`. So AFAIU CLC was never a correct body for ecosystem-wide changes. (FWIW I’m hugely interested in AFPP and happy to help in my personal capacity) Best regards, Andrew

On 31 Oct 2021, at 09:49, Julian Ospald wrote:

That sounds rather disappointing to me.

So what has been done to reboot the CLC is:

1. add more people and 2. narrow the scope and offload ecosystem issues to the Haskell Foundation?

I've been trying to get input from the CLC for the past year on an issue that affects potentially all of core libraries and I don't think it's feasible to contact all of the maintainers isolated.

Does that mean CLC won't assist me in contacting core library maintainers and moderating a discussion?

On Sun, Oct 31, 2021 at 12:23:57AM +0100, Andrew Lelechenko wrote:

...

As https://github.com/haskell/core-libraries-committee/blob/main/README.md says, CLC owns, but does not maintain core libraries as long as they are kept in order by appointed maintainers. If you find a core library abandoned and neglected, raise an issue with CLC.

Otherwise proposals affecting core libraries should be discussed with respective maintainers first. They can seek CLC opinion on controversial changes, but are not obliged to.

I suppose HF Tech Track could be a helpful body to ask a non-binding opinion on changes with a wider scope.

Best regards, Andrew

On 31 Oct 2021, at 00:08, Julian Ospald wrote:

Do I understand correctly that the CLC only governs base now?

If not, where does one raise other issues that potentially affect core libraries?

On October 30, 2021 8:13:18 PM UTC, Andrew Lelechenko < andrew.lelechenko@gmail.com> wrote:

I'm happy to announce that Core Libraries Committee has completed post-election reboot and now has a new home at https://github.com/ haskell/core-libraries-committee and a new GitHub-based process: https: //github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md.

From now on proposals to change base should be raised as GitHub issues instead of emails to libraries@.

Best regards, Andrew

| 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? The doc also says that if a core-library maintainer becomes unresponsive, the CLC will seek another. What's not so clear to me is what makes a library into a "Core library". Can non-core libraries become core? And vice versa? What's the criterion? I suppose it could simply be historical, but that seems less than ideal. I welcome the CLC reboot, especially having a process so that we know what issues are in play, and what decisions have been taken. Simon [1] https://github.com/haskell/core-libraries-committee PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com will cease to work. Use simon.peytonjones@gmail.com instead. (For now, it just forwards to simonpj@microsoft.com.) | -----Original Message----- | From: Libraries On Behalf Of Julian | Ospald | Sent: 02 November 2021 18:40 | To: Andrew Lelechenko | Cc: libraries@haskell.org | Subject: Re: New CLC proposal process | | Well, | | this confirms my disappointment. | | Wasn't the intention of a reboot to fix the disengagement of the | current CLC? | | From reading this thread, my impression is rather that this | disengagement has been formalized in the form of a proposal process | and a statement that the "Core libraries comittee" is no longer | responsible for the "Core libraries", which I find rather odd. | | It is my personal impression that the community wants an engaged CLC | that is able to moderate discussions, help with projects related to | the core libraries and possibly make decisions that are entirely | technical and bear no political nuances. | | 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. | | Cheers, | Julian | | | On Sun, Oct 31, 2021 at 12:01:55PM +0000, Andrew Lelechenko wrote: | > 1. On contrary, we narrowed CLC from 9 to 6 members to make it more | manageable. | > | > 2. CLC was incapable to deal with wider ecosystem issues for years. | It is better not to nourish false hopes. | > | > I believe in "Make each committee do one thing well". CLC's primary | and undivided responsibility is `base` and, as witnessed by a huge | backlog, even this single thing was handled below expectations. It's | not like we are in a good position to accept additional, wider | responsibilities. | > | > Remember that "core libraries" is an abstract moniker without much | consistency: e. g., before very recent `text` was not core, and it | includes `mtl`, but not `transformers`, and does not include | `containers`. So AFAIU CLC was never a correct body for ecosystem-wide | changes. | > | > (FWIW I'm hugely interested in AFPP and happy to help in my personal | > capacity) | > | > Best regards, | > Andrew | > | > > On 31 Oct 2021, at 09:49, Julian Ospald | wrote: | > > | > > That sounds rather disappointing to me. | > > | > > So what has been done to reboot the CLC is: | > > | > > 1. add more people and | > > 2. narrow the scope and offload ecosystem issues to the Haskell | > > Foundation? | > > | > > I've been trying to get input from the CLC for the past year on an | > > issue that affects potentially all of core libraries and I don't | > > think it's feasible to contact all of the maintainers isolated. | > > | > > Does that mean CLC won't assist me in contacting core library | > > maintainers and moderating a discussion? | > > | > > | > > On Sun, Oct 31, 2021 at 12:23:57AM +0100, Andrew Lelechenko wrote: | > >> As | > >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg | > >> ithub.com%2Fhaskell%2Fcore-libraries- | committee%2Fblob%2Fmain%2FREAD | > >> | ME.md&data=04%7C01%7Csimonpj%40microsoft.com%7Cf8f41ef7b86e4c0e | > >> | 95da08d99e30436c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63771 | > >> | 4752441971356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | > >> | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bSfoLPWt2rMe | > >> P1mMkImk2U5jOM39BI%2FBDNtHisaKeIY%3D&reserved=0 | > >> says, CLC owns, but does not maintain core libraries as long as | > >> they are kept in order by appointed maintainers. If you find a | core | > >> library abandoned and neglected, raise an issue with CLC. | > >> | > >> Otherwise proposals affecting core libraries should be discussed | > >> with respective maintainers first. They can seek CLC opinion on | > >> controversial changes, but are not obliged to. | > >> | > >> I suppose HF Tech Track could be a helpful body to ask a | > >> non-binding opinion on changes with a wider scope. | > >> | > >> Best regards, | > >> Andrew | > >> | > >> | > >> On 31 Oct 2021, at 00:08, Julian Ospald | wrote: | > >> | > >> Do I understand correctly that the CLC only governs base now? | > >> | > >> If not, where does one raise other issues that potentially | affect core | > >> libraries? | > >> | > >> On October 30, 2021 8:13:18 PM UTC, Andrew Lelechenko < | > >> andrew.lelechenko@gmail.com> wrote: | > >> | > >> | > >> I'm happy to announce that Core Libraries Committee has | completed | > >> post-election reboot and now has a new home at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cf8f41ef7b86e4c0 | e95da08d99e30436c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6377147 | 52441971356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PV%2BwQ3dDsgZsFB%2FJ | gTvCJ6%2BnaMCLY0pxWmG2GrOuTrI%3D&reserved=0 | > >> haskell/core-libraries-committee and a new GitHub-based | process: https: | > >> //github.com/haskell/core-libraries- | committee/blob/main/PROPOSALS.md. | > >> | > >> From now on proposals to change base should be raised as | GitHub issues | > >> instead of emails to libraries@. | > >> | > >> Best regards, | > >> Andrew | > >> | > >> | > | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | haskell.org%2Fcgi- | bin%2Fmailman%2Flistinfo%2Flibraries&data=04%7C01%7Csimonpj%40micr | osoft.com%7Cf8f41ef7b86e4c0e95da08d99e30436c%7C72f988bf86f141af91ab2d7 | cd011db47%7C1%7C0%7C637714752441971356%7CUnknown%7CTWFpbGZsb3d8eyJWIjo | iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& | ;sdata=eaBTod9nh0hgY6vBatTLNYSd1vfPTNY8LKDd89wmyy0%3D&reserved=0

In that analogy though, when a private property is redeemed, the public pays for that, and then owns and develops it further. You just enjoy the fame of your great-grand-ancestors. - Oleg On 3.11.2021 11.43, Andreas Abel wrote:

...

What's not so clear to me is what makes a library into a "Core library". Can non-core libraries become core?  And vice versa?  What's the criterion?

As a human settlement evolves and grows, the need for more coordination and governance arises.  Maybe one of my great-grand-ancestors build and maintained a road from his farm to a shed.  But over the centuries both the farm and the shed evolved into villages, and the once private road is now essential for the lives of many.  So the community will assume ownership of the once private road.

In the same way, a "state of Haskell" is now emerging, and we cannot just rely on private maintenance of packages that are essential to the Haskell ecosystem.

What a criterion could be?  For a start, the order of magnitude on how many live packages rely on a certain package.

--Andreas

On 2021-11-03 10:17, Simon Peyton Jones via Libraries 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?

The doc also says that if a core-library maintainer becomes unresponsive, the CLC will seek another.

What's not so clear to me is what makes a library into a "Core library". Can non-core libraries become core?  And vice versa?  What's the criterion?  I suppose it could simply be historical, but that seems less than ideal.

I welcome the CLC reboot, especially having a process so that we know what issues are in play, and what decisions have been taken.

Simon

[1] https://github.com/haskell/core-libraries-committee

PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com will cease to work.  Use simon.peytonjones@gmail.com instead.  (For now, it just forwards to simonpj@microsoft.com.)

|  -----Original Message----- |  From: Libraries On Behalf Of Julian |  Ospald |  Sent: 02 November 2021 18:40 |  To: Andrew Lelechenko |  Cc: libraries@haskell.org |  Subject: Re: New CLC proposal process | |  Well, | |  this confirms my disappointment. | |  Wasn't the intention of a reboot to fix the disengagement of the |  current CLC? | |  From reading this thread, my impression is rather that this |  disengagement has been formalized in the form of a proposal process |  and a statement that the "Core libraries comittee" is no longer |  responsible for the "Core libraries", which I find rather odd. | |  It is my personal impression that the community wants an engaged CLC |  that is able to moderate discussions, help with projects related to |  the core libraries and possibly make decisions that are entirely |  technical and bear no political nuances. | |  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. | |  Cheers, |  Julian | | |  On Sun, Oct 31, 2021 at 12:01:55PM +0000, Andrew Lelechenko wrote: |  > 1. On contrary, we narrowed CLC from 9 to 6 members to make it more |  manageable. |  > |  > 2. CLC was incapable to deal with wider ecosystem issues for years. |  It is better not to nourish false hopes. |  > |  > I believe in "Make each committee do one thing well". CLC's primary |  and undivided responsibility is `base` and, as witnessed by a huge |  backlog, even this single thing was handled below expectations. It's |  not like we are in a good position to accept additional, wider |  responsibilities. |  > |  > Remember that "core libraries" is an abstract moniker without much |  consistency: e. g., before very recent `text` was not core, and it |  includes `mtl`, but not `transformers`, and does not include |  `containers`. So AFAIU CLC was never a correct body for ecosystem-wide |  changes. |  > |  > (FWIW I'm hugely interested in AFPP and happy to help in my personal |  > capacity) |  > |  > Best regards, |  > Andrew |  > |  > > On 31 Oct 2021, at 09:49, Julian Ospald |  wrote: |  > > |  > > That sounds rather disappointing to me. |  > > |  > > So what has been done to reboot the CLC is: |  > > |  > > 1. add more people and |  > > 2. narrow the scope and offload ecosystem issues to the Haskell |  > >   Foundation? |  > > |  > > I've been trying to get input from the CLC for the past year on an |  > > issue that affects potentially all of core libraries and I don't |  > > think it's feasible to contact all of the maintainers isolated. |  > > |  > > Does that mean CLC won't assist me in contacting core library |  > > maintainers and moderating a discussion? |  > > |  > > |  > > On Sun, Oct 31, 2021 at 12:23:57AM +0100, Andrew Lelechenko wrote: |  > >> As |  > >> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg |  > >> ithub.com%2Fhaskell%2Fcore-libraries- |  committee%2Fblob%2Fmain%2FREAD |  > >> |  ME.md&data=04%7C01%7Csimonpj%40microsoft.com%7Cf8f41ef7b86e4c0e |  > >> |  95da08d99e30436c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63771 |  > >> |  4752441971356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV |  > >> |  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bSfoLPWt2rMe |  > >> P1mMkImk2U5jOM39BI%2FBDNtHisaKeIY%3D&reserved=0 |  > >> says, CLC owns, but does not maintain core libraries as long as |  > >> they are kept in order by appointed maintainers. If you find a |  core |  > >> library abandoned and neglected, raise an issue with CLC. |  > >> |  > >> Otherwise proposals affecting core libraries should be discussed |  > >> with respective maintainers first. They can seek CLC opinion on |  > >> controversial changes, but are not obliged to. |  > >> |  > >> I suppose HF Tech Track could be a helpful body to ask a |  > >> non-binding opinion on changes with a wider scope. |  > >> |  > >> Best regards, |  > >> Andrew |  > >> |  > >> |  > >>    On 31 Oct 2021, at 00:08, Julian Ospald |  wrote: |  > >> |  > >>    Do I understand correctly that the CLC only governs base now? |  > >> |  > >>    If not, where does one raise other issues that potentially |  affect core |  > >>    libraries? |  > >> |  > >>    On October 30, 2021 8:13:18 PM UTC, Andrew Lelechenko < |  > >>    andrew.lelechenko@gmail.com> wrote: |  > >> |  > >> |  > >>        I'm happy to announce that Core Libraries Committee has |  completed |  > >>        post-election reboot and now has a new home at |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith |  ub.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cf8f41ef7b86e4c0 |  e95da08d99e30436c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6377147 |  52441971356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PV%2BwQ3dDsgZsFB%2FJ |  gTvCJ6%2BnaMCLY0pxWmG2GrOuTrI%3D&reserved=0 |  > >>        haskell/core-libraries-committee and a new GitHub-based |  process: https: |  > >>        //github.com/haskell/core-libraries- |  committee/blob/main/PROPOSALS.md. |  > >> |  > >>        From now on proposals to change base should be raised as |  GitHub issues |  > >>        instead of emails to libraries@. |  > >> |  > >>        Best regards, |  > >>        Andrew |  > >> |  > >> |  > |  _______________________________________________ |  Libraries mailing list |  Libraries@haskell.org |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. |  haskell.org%2Fcgi- |  bin%2Fmailman%2Flistinfo%2Flibraries&data=04%7C01%7Csimonpj%40micr |  osoft.com%7Cf8f41ef7b86e4c0e95da08d99e30436c%7C72f988bf86f141af91ab2d7 |  cd011db47%7C1%7C0%7C637714752441971356%7CUnknown%7CTWFpbGZsb3d8eyJWIjo |  iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& |  ;sdata=eaBTod9nh0hgY6vBatTLNYSd1vfPTNY8LKDd89wmyy0%3D&reserved=0 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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 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-9574049... [2] https://mail.haskell.org/pipermail/libraries/2015-June/025852.html [3] https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp... [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/acce... [7] https://github.com/haskell/text/blob/7a492ecff429748386dbde7da0db45a0bfb8dcd... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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 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-9574049... [2] https://mail.haskell.org/pipermail/libraries/2015-June/025852.html [3] https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp... [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/acce... [7] https://github.com/haskell/text/blob/7a492ecff429748386dbde7da0db45a0bfb8dcd...