I'd like to clarify that I actually support moving the proposal discussions to something easier to track and search. I'm just not that pleased with the way the announcement came down from on high. On Fri, Sep 11, 2020, 11:47 PM David Feuer wrote:

In terms of decision-making process for this new process, I must agree with Carter. To the best of my knowledge, neither CLC nor the GHC steering committee have general authority to make decisions about libraries on behalf of the community without first going through the mailing list proposal process. As far as I'm concerned, that should include changing said process. Any discussions that happened in private must be considered mere preparation for formal process, which should begin on the libraries list.

On Fri, Sep 11, 2020, 11:36 PM Carter Schonwald < carter.schonwald@gmail.com> 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.

A proposals process / formal process isn’t always a win. This sortah approach demands a lot more dedicated human power and support admin than I think is tenable for the libraries ecosystem today.

Merry Friday and be well -Carter

---------- Forwarded message --------- From: chessai Date: Fri, Sep 11, 2020 at 10:02 PM Subject: Re: New Libraries Proposal process To: Carter Schonwald

This has been discussed on and off for a few months now, amongst CLC, between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK, Serokell, etc. My only regret is that a lot of the conversation happened privately.

...

All libraries process needs to start on the libraries mailing list

Not anymore.

The libraries mailing list has proven to be ineffective when it comes to getting stuff done. Mailing lists are not the right format for this. Furthermore, I don't see how emails are more conducive to deep discussion than github comments. There are many GitHub issue trackers and PRs which show otherwise.

This new process will never be perfect and of course will need some tweaking, but the current process is very poor and gets little done. Most proposals I ever see end up with no resolution.

Since the GHC Proposals process has proven to be a net positive, much of the structure was taken from there and adapted to core libraries.

On Fri, Sep 11, 2020, 19:52 Carter Schonwald wrote:

...

Where was this discussed or proposed? All libraries process needs to start on the libraries mailing list. And soemtimes Perhaps moving to clc list for resolving tie breaking on controversial choices.

The libraries archive goes back pretty far and email threading seems to scale far better for participating in complex discussions than does githubs comment collapsing on large discussions.

On Fri, Sep 11, 2020 at 3:20 PM chessai wrote:

...

All,

There is a new Libraries Proposal process, inspired by the GHC Proposals process.

Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive.

Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with.

I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.

_______________________________________________

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

On Sat, 12 Sep 2020, at 2:44 PM, Bertram Felgenhauer via Libraries wrote:

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://github.com/haskell-core/core-libraries-proposals

fails to do that for observers.

Could you explain why this fails? I watch the ghc-proposals GitHub project and get notified of all comments, so feel as an observer my needs are well catered for. Furthermore, having each proposal be a PR can let me see how a discussion is factored back in to the proposal, as comments become a diff. What do you feel a ML has that GitHub + watching does not have?

One thing I find valuable with the GitHub proposal style—which I've observed in GHC proposals and in Rust—is that each proposal has a document that contains all of the information and gets updated over time. Later on, it's nice to read the final version of a proposal document without needing to go into all of the discussion that led up to it. We could still do that while having discussions on a mailing list, of course, but it seems that GitHub makes the connection between discussions and the proposal document more direct. On Sat, Sep 12, 2020, 09:15 Bertram Felgenhauer via Libraries < libraries@haskell.org> wrote:

Oliver Charles wrote:

...

On Sat, 12 Sep 2020, at 2:44 PM, Bertram Felgenhauer via Libraries wrote:

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

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

fails to do that for observers.

Could you explain why this fails? I watch the ghc-proposals GitHub project and get notified of all comments, so feel as an observer my needs are well catered for. Furthermore, having each proposal be a PR can let me see how a discussion is factored back in to the proposal, as comments become a diff.

Unless somebody force-pushes a new version, in which case I think the old version is lost forever.

...

What do you feel a ML has that GitHub + watching does not have?

I suppose that works, for people with a GitHub account (possibly a strawman; I do have one). But it should be mentioned somewhere! The experience can also be improved by conventions. For example, I'd like the PRs that constitute proposals to come with a synopsis of the proposal as the description, because the descriptions end up in the notifications, whereas the actual commits do not. So to avoid having to check every proposal on GitHub, such a synopsis would be useful. Maybe this should be self-evident, but it's not mentioned in the README document.

There's also the loss of threading mentioned elsewhere. I cannot say how bad this is in practice (I delete GitHub notifications after reading them). We can see in the libraries archive that for larger proposals we often have several subthreads about different aspects of the proposal (and I frequently skip over whole subthreads when I'm not intersted the aspect under consideration).

I also find that with email it's easy to send a comment just to the author (e.g. for typos). GitHub makes this harder (I suppose you /can/ open a ticket in the author's clone of the repo...).

And, obviously, there's resistance to change.

While we're comparing these things, what are the problems that the new process is meant to solve?

Cheers,

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

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://github.com/haskell-core/core-libraries-proposals

fails to do that for observers.

Cheers,

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

| 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

Carter Schonwald writes:

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

For what it's worth, I agree that it would be beneficial to have a more formal libraries proposal process. The current process has a number of shortcomings: * it has shown itself to be lossy; that is, proposals are sometimes lost * intransparent: I have found it difficult to locate clear conclusions on mailing lists threads when evaluating ghc core libraries MRs. * difficult to audit: when one does find a message that looks authoritative are carries a clear conclusion, it often isn't clear whether this is the opinion of the body as a whole, or simply one member. * may be poorly representative: recently most of my interactions with the CLC have been by pinging @core-libraries on GHC MRs, where I get at most one or two replies. My fear is that while the nominal size of the body is ~9 members, only a few members are actively engaged, suggesting that there may be a deeper problem with the structure of the body In my opinion the opening of Carter's message ("I think ...") captures the problem here rather well: there is no single place where conclusions are clearly articulated and flagged as such. All we can do is trawl through mailing list threads of yore and attempt to reconstruct the collective state-of-mind of the committee. This is what Chessai's proposal seeks to fix.

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.

I don't believe anyone is suggesting that the process should require a full-time employee to manage. Rather, I would point to the GHC Proposals process as a process that is reasonably formal, effective, and yet operates on relatively little time investment by its steering committee. Given that the CLC's responsibilities are at least as important as those of the GHC Steering committee, I see little reason why this couldn't, or shouldn't, be replicated. Of course, any more formal process will likely require time investment than the status quo. To this end, I think it would be beneficial for the CLC to discusss the expected time commitment required by the body and what time individual members are able to provide. If the time investment necessary for an improved process is greater than the volunteer effort available then there are three options: (a) scale down the process, (b) increase the size of the committee, or (c) kindly thank existing members who aren't able to put effort into the body for their service and ask that they step down.

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.

I completely agree with your last sentence. However, in light of this I'm not sure I understand the point made in your first sentence: What new authority are you seeing in Chessai's proposal? Cheers, - Ben