State of the CLC [wrt MLs]

Thu Aug 12 16:24:47 UTC 2021

I totally agree.

Here's where we need active moderation. While a thread develops, I'd expect the moderator at one point to set a stop sign, gather the different ideas, summarize them as a reply to the top-post with the subject changed and then have CLC do their voting. That way, CLC members not actively participating in the thread can get a reasonable overview of the options.

The outcome should be posted as a reply to that mail, however, as you pointed out, ML is not a structured document.

I'd say it's up to the discretion of the CLC to choose and maintain a record of the discussions and their status and the decisions, be that google docs, a gitlab repo etc., containing ML archive links and other relevant resources.

On August 12, 2021 3:20:46 PM UTC, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>Fair enough Julian.  Any system that allows rapid, unequivocal, and universally-agreed answers to the questions I list below would be fine with me.  I don't quite see how email can do that (e.g. press a button to list the proposals under committee review), but if it can, so much the better.
>
>Oh, I should add one more:
>
>  *   What exactly is the proposal that the committee has accepted?   One should be able to answer that by pointing to a (perhaps short) document or PR.   It is much much less good to reply "It's the proposal made in this email, and then modified and fine-tuned by the following 20".
>Email is good for the process and discussion; it is less good at recording the outcome and decision.
>
>Simon
>
>From: Julian Ospald <hasufell at posteo.de>
>Sent: 12 August 2021 13:49
>To: Simon Peyton Jones <simonpj at microsoft.com>; Emily Pillmore <emilypi at cohomolo.gy>
>Cc: libraries at haskell.org
>Subject: RE: State of the CLC [wrt MLs]
>
>I'm not sure Simon,
>
>many projects larger than the CLC are using mailing lists with much higher throughput:
>
>* https://lkml.org/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cd9215912b49e402d28be08d95d8f9554%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637643694023501652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8%2B3O7hc7QkhUOPeyEXK3HIPKzqW9Kr2AsvB4GFsEarE%3D&reserved=0>
>* https://archives.gentoo.org/gentoo-dev/threads<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchives.gentoo.org%2Fgentoo-dev%2Fthreads&data=04%7C01%7Csimonpj%40microsoft.com%7Cd9215912b49e402d28be08d95d8f9554%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637643694023501652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3AEfaSEX3fFuw%2FALzYaUaLFVVBmF3AAvqKTGAPbMH1E%3D&reserved=0>
>* https://lists.debian.org/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.debian.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cd9215912b49e402d28be08d95d8f9554%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637643694023511649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oPR0I3PZpkGOKvj0miHID3QYGlPX8HHUqomYymIxpyM%3D&reserved=0>
>
>These have done so for decades and had enough time to consider alternatives.
>
>To get into more detail:
>
>1. Mails have threads! But one has to use them properly. The subject when creating a reply can be adjusted as well.
>2. Cross-posting is very easy. Much easier than jumping between reddit, discourse and github PRs.
>3. They can be used for patches and reviews as well and many projects still use this mechanism. You don't even have to use git for that. I'm not advocating for that, but it shows that it's a very simple and powerful communication tool, even today.
>4. They are persistent and searchable through ML archives.
>
>I believe this just boils down to communication discipline and moderation. In lack of both, I believe no matter the tool, the experience won't be pleasant (issue tracker discussions are worse imo, since they often don't have good threading).
>
>Cheers,
>Julian
>On August 12, 2021 8:00:30 AM UTC, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>I'd like to suggest that a mailing list isn't good even for mis-sized contributions.
>
>One of the difficulties of managing the CLC process is that it often consists of a number of small proposals, all in flight.  It's very easy for them to get lost and - especially because they are small - that is very frustrating for the contributor.
>
>I think it would help to have mechanical support of some kind, that makes it easy to answer questions like
>
>
>  *   What proposed changes to `base` and `ghc-prim` are in flight?   (No matter how small!)
>  *   Which of those changes are in "open-discussion" mode (relaxed timescale), and which have been submitted to the committee for decision (fixed timescale).  For the latter, on what date was the proposal submitted?
>  *   What decisions has the committee taken?  To accept, or reject, or push-back a proposal?
>
>A mailing list is poorly adapted to answering these questions.   But I think much frustration arises not because anyone is being lazy or negligent, but simply because volunteers are busy, and it's hard to keep multiple threads going in your head and all too easy for them to drift - sometimes for ever.
>
>It's almost more important to do this to keep track of the many small proposals than for the few big ones.
>
>Using PRs is one sort of mechanical support, provided there is some kind of tagging giving the status (in-discussion, under-committee-review, accepted, rejected) of each.
>
>I'm not directly involved in CLC, so these are just suggestions.
>
>Simon
>
>From: Libraries <libraries-bounces at haskell.org> On Behalf Of Emily Pillmore
>Sent: 12 August 2021 00:16
>To: Julian Ospald <hasufell at posteo.de>
>Cc: libraries at haskell.org
>Subject: Re: State of the CLC
>
>You really know how to get right to the heart of where I'm being intentionally vague and asking questions about it! :)
>
>I can speak a little bit to your questions, but the technical details of the proposal were intentionally left out because we simply haven't convened to discuss anything in concretions yet. However, I can give you my thoughts on where I'd like to take this, personally:
>Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries)
>
>A contribution process is one part of it, and it's a little more complicated than the situation you describe. Mainly, yes, a contribution process exists and the CLC has been historically poor at answering the call. However, this is not simply because the CLC has been derelict - my contention is that it was never very efficient, and has simply been completely defunct for some time now. Here are some thoughts I have on the matter off the top of my head for how we can improve things:
>
>  1.  I feel (as do others in the CLC and outside of it) that the mailing list is good for some contributions, but poor for others. Namely, some contributions to base are small enough that they should occur as a pull request against `base`, a ping to the CLC, and we should review it without getting everyone who monitors this list involved. Historically, contributions that are small in scope, and possibly trivial quality of life contributions are defeated by bikeshedding. Too many cooks is a very real phenomenon in this mailing list. We would like to make sure that the process for deciding where to submit an idea is well documented, and that it is a separate avenue.
>  2.  For mid-sized contributions, the mailing list is great! However, there does seem to be a culture, particularly in this list of not being oriented towards solutions. There is not enough skin in the game. I get the impression in many cases (and others have expressed similar complaints) that  many interactions are simply "gotcha"-style intellectual mounting games instead of solution finding, and this causes alot of frustration consistently enough for people to voice the complaint to me.
>  3.  For larger contributions, like the Abstract file path proposal, I think a mailing list is perhaps too small a forum to discuss it, and it would be better served by a GHC proposal-style process that is more open for comment, searchable, and and history not so scattered. Further, without a project manager for larger contributions, these things get lost easily, and we would like to solve that by adding a role, and reworking the process for larger, overarching changes to `base`.
>  4.  Mailing lists are generally not friendly to searches, history, or finding out who's in charge of what.
>
>In addition to this, what I have in mind is to add more members to the CLC, to allow for a more fluid process for onboarding and offboarding CLC members as they become or fall out of availability. I would also like to lower the bar, as you suggested on Reddit might be a good idea. I don't think requiring galaxy brains is the right tack we need to take. I would rather have productive engineers who can bring new ideas to the table about how to improve the state of `base`.
>
>contribution pipeline through the HF?
>
>This is not in our plans, though, we have spoken a little bit about whether or not someone from the HF could serve as a shepherd for issues and CLC member wrangler. However, I don't think this would be in any official HF capacity as much as it would be a good will gesture. Mainly though, a project manager is in our interests, be it an HF person or not.
>
>Cheers,
>Emily
>
>
>
>
>
>
>
>On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald <hasufell at posteo.de<mailto:hasufell at posteo.de>> wrote:
>
>On August 10, 2021 9:01:22 PM UTC, Emily Pillmore <emilypi at cohomolo.gy<mailto:emilypi at cohomolo.gy>> wrote:
>
>I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors.
>
>Can you be more precise here? Is it simply about creating a contribution process (which already exists afaik, it's just that you barely get any response for core libraries) or is the idea to run part of the contribution pipeline through the HF?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210812/bab7c484/attachment-0001.html>