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 On Behalf Of Emily Pillmore
Sent: 12 August 2021 00:16
To: Julian Ospald
Cc: libraries@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 mailto:hasufell@posteo.de> wrote:
On August 10, 2021 9:01:22 PM UTC, Emily Pillmore mailto:emilypi@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?
