State of the CLC [wrt MLs]

Thu Aug 12 18:54:47 UTC 2021

Yeah that’s def been needed for the longest time.

On Thu, Aug 12, 2021 at 10:52 AM Julian Ospald <hasufell at posteo.de> wrote:

> Absolutely.
>
> I propose to make this a role: CLC secretary. Someone actively moderating
> discussions, ensuring community participation on proposals, summarizing
> results, maintaining the records.
>
> The same person may be part of the CLC committee, but doesn't need to be.
>
> Cheers,
> Julian
>
>
> On August 12, 2021 5:04:30 PM UTC, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>>
>> 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.
>>
>>
>>
>> I’m totally with you on that.   The CLC should decide how the CLC should
>> operate.   I’m just trying to contribute constructively to the debate.
>>
>>
>>
>> Simon
>>
>>
>>
>>
>>
>> *From:* Julian Ospald <hasufell at posteo.de>
>> *Sent:* 12 August 2021 17:25
>> *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 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%7C286c49c5368747b4480b08d95dadb563%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637643822980483326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XqK%2Bu80jwju5MyR4p%2BHM4GLQ8lF%2F9wRoUSGEU%2FIKG%2BU%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%7C286c49c5368747b4480b08d95dadb563%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637643822980493321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=grM5ED4%2FUJo4ITl3xLZgd5p3Py4Juq6dGu4gUjh3zFc%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%7C286c49c5368747b4480b08d95dadb563%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637643822980493321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=p2Yog%2Br9nunNq7Uasne8aIw22o3z%2FVEMaLx5aewQsBk%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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> [image: Image removed by sender.]
>>
>>
>>
>>
>>
>> On Tue, Aug 10, 2021 at 11:52 PM, Julian Ospald <hasufell at posteo.de>
>> wrote:
>>
>> On August 10, 2021 9:01:22 PM UTC, Emily Pillmore <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?
>>
>>
>>
>> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210812/2a88004c/attachment-0001.html>