Regarding dupe Re: New Libraries Proposal process

I think wrt to the dup/dupe proposal the answer at the time was nope. 1) there wasn’t a clear name that wouldn’t collide with user code 2) it wasn’t clear that it provided new expressive power / reduced complexity. To be clear, there’s a higher bar for adding / changing exports of preexisting modules, and preexisting wide spread conventions in programming practice is often a good way to motivate including such operations. Or that it adds a meaningful abstraction that helps all users. Also there didn’t seem to be much wide spread support in the discussion that followed. @simon : that process doesn’t have clear buy in by those who participate actively in the libraries ecosystem. And raises questions around 1) I don’t think we have enough volunteer effort to actually manage / support Such a process (it’s tantamount to expecting full time professionalization expectations for libraries core contrib... which I think our community and industrial sponsorship isn’t large enough to facilitate. ). Plus that dramatically increases the participation expectations / requirements from clc members. 2) it creates authority that frankly clc did not have before. (Ed and others who have been part of clc historically please correct me if I’m wrong). Clc is supposed to be a facilitator and tie breaker and guider of evolution of base and a mechanisms for engaging in community consensus of how to improve important libraries. 3) if we are to have an entity which we will call clc but WILL have more authority than being a Coordination point for community collab and agreement, I strongly suggest we ground this in what a reboot with a more open selection / participation structure as guards / rail posts to ensure Adequate community representation and enablement. All authority is a social construct, and frankly if we are giving these leadership elements more formal authority there needs to be bylaws or other such structure to make sure process and communication function and accountability exists. On Wed, Sep 16, 2020 at 12:40 PM Simon Peyton Jones via Libraries < libraries@haskell.org> wrote:

| adding `\x → (x, x)` to `Data.Tuple`.[1] It was akin to throwing a

| stone into a pond — there may be a splash, a few responses, but in the

| end nothing is accomplished.

That has indeed been a problem. But the process Chessai has described should eliminate the problem.

* You write a short proposal (20 mins work)

* You submit it to the committee

* It lands on their machine-supported to-do list

* You should get a yes or no decision within the timescale

specified by the process

So you throw in the stone, and something happens, even if it's "thank you but no".

| So now it looks like things are going to get even more industry and

| research oriented, even less friendly to people of common standing.

| Has any thought been given to that?

You are not the only person who has expressed these sentiments. These responses have made it clear that it's easy to interpret the proposed new process as adding new slow and bureaucratic overheads. I think we should try to make clearer that, quite to the contrary, it's designed to make sure that every proposal gets timely attention.

Simon

| -----Original Message-----

| From: Libraries On Behalf Of Ignat Insarov

| Sent: 16 September 2020 17:29

| To: amindfv@mailbox.org

| Cc: Bertram Felgenhauer via Libraries

| Subject: Re: New Libraries Proposal process

|

| I apologise for intrusion but I have a question.

|

| I would like to ask if all this was ever supposed to work for simple

| folk — a hobbyist or a small-time freelancer. _(I am that.)_ I tried

| bringing up small _«proposals»_ on this list previously, such as

| adding `\x → (x, x)` to `Data.Tuple`.[1] It was akin to throwing a

| stone into a pond — there may be a splash, a few responses, but in the

| end nothing is accomplished. On the other hand, bringing issues up on

| the issue tracker of an individual package would result in a rebuttal

| with a reference to the higher authority of the faceless crowd on the

| mailing list.[2]

|

| So now it looks like things are going to get even more industry and

| research oriented, even less friendly to people of common standing.

| Has any thought been given to that?

|

| [1]:

| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske

| ll.org%2Fpipermail%2Flibraries%2F2019-

| July%2F029747.html&data=02%7C01%7Csimonpj%40microsoft.com %7C2ca841705125

| 4bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373587055

| 20838463&sdata=oTK%2Fkx6PaRa1jct92polqMfGddaqGZiIkyhIQaivSOg%3D&rese

| rved=0

| [2]:

| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com

| %2Fhaskell%2Fcontainers%2Fissues%2F744&data=02%7C01%7Csimonpj%40microsof

| t.com %7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%

| 7C1%7C0%7C637358705520838463&sdata=U6iXUJLRGktuwTrO5bwX4HwmKrR1rAdoPEsBZ

| bPdJd0%3D&reserved=0

|

|

| On Sun, 13 Sep 2020 at 04:26, amindfv@mailbox.org

| wrote:

| >

| > I'd like to +1 everything said here, and say as an observer it's strange

| to have the decision made privately and announced here as a fait accompli.

| >

| > Another thing to note about email is that it's decentralized and has (and

| presumably always will have) plenty of clients and tools. I've seen

| discussions linking to email conversations that are significantly older than

| GitHub itself - there's value to archives of old discussions. If GitHub

| folds or starts charging money or redesigns its site in an unhelpful way,

| all discussion would be lost or made less accessible. Whereas mailing list

| archives can jump to new hosts indefinitely.

| >

| > Tom

| >

| >

| > On Sat, Sep 12, 2020 at 03:44:10PM +0200, Bertram Felgenhauer via

| Libraries wrote:

| > > Carter Schonwald wrote:

| > > > Are you sure about this approach? I think you need to start with an

| > > > open discussion , And have a open ended thread about ideas for how to

| > > > improve how we do things.

| > >

| > > I totally agree with this, though fleshing out ideas in a smaller

| > > forum first is helpful.

| > >

| > > An important consideration here is that there are several types of

| > > stakeholders in the library proposal process, including

| > >

| > > * the CLC members, who ultimately decide on core library changes;

| > > * proponents ("authors"), who originate proposals for such changes;

| > > and

| > > * observers ("the wider Haskell community"), users of the core

| > > libraries who want to keep track of upcoming library changes and

| > > chime in when a proposal affects their own uses of a library.

| > >

| > > I suspect that the observers are a silent majority, and that a mailing

| > > list with public archives is close to optimal for them. (I consider

| > > myself an observer and I do like the mailing list for precisely this

| > > reason. But I also grew up with mailing lists, not forums, so I'm

| > > surely biased here.)

| > >

| > > In any case I think that any change to the library proposal process

| > > should cater to all three types of stakeholders (and possibly others

| > > I have failed to think of). In its current form, I believe

| > >

| > >

| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com

| %2Fhaskell-core%2Fcore-libraries-

| proposals&data=02%7C01%7Csimonpj%40microsoft.com %7C2ca8417051254bd720560

| 8d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637358705520838463&

| amp;sdata=bOP4zOD6oPG8p5EnSJPr2EeTFGWfMrggpYrLVmS9xgA%3D&reserved=0

| > >

| > > fails to do that for observers.

| > >

| > > Cheers,

| > >

| > > Bertram

| > > _______________________________________________

| > > Libraries mailing list

| > > Libraries@haskell.org

| > >

| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel

| l.org%2Fcgi-

| bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.

| com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C

| 1%7C0%7C637358705520838463&sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F

| TCoXp9CI%3D&reserved=0

| > _______________________________________________

| > Libraries mailing list

| > Libraries@haskell.org

| >

| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel

| l.org%2Fcgi-

| bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.

| com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C

| 1%7C0%7C637358705520838463&sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F

| TCoXp9CI%3D&reserved=0

| _______________________________________________

| Libraries mailing list

| Libraries@haskell.org

| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel

| l.org%2Fcgi-

| bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.

| com%7C2ca8417051254bd7205608d85a5da425%7C72f988bf86f141af91ab2d7cd011db47%7C

| 1%7C0%7C637358705520838463&sdata=htbnzKwMR22jhgKRrkWWH%2BS4KQfHs5rKsJ%2F

| TCoXp9CI%3D&reserved=0

_______________________________________________

Libraries mailing list

Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries