First draft of the cabal-proposals process #11006
Conversation
The cabal developers are interested to adopt a proposal process, the details are found in the `proposals.md` file. The process is designed to make developers feel empowered to make decisions. * It is light-weight, a PR is opened and discussed on a repo with a fixed discussion period. * It is developer-led, final decisions are made by developers at the Cabal developers meeting. * It is flexible, there is no formal voting procedure, decisions are made by rough consensus. Overall, we hope that this will allow developers to move the cabal project forward.
|
A discussion issue for this topic: #11007 |
|
Since the draft references Does “no one feels confident in making that change without a clearer mandate or process” apply there? It seems to me there are a lot of obstacles (Agda, Hackage builder, GHCJS, nix) which where mentioned in the ticket, and — understandably, given they are all non-trivial — silence after that. |
Co-authored-by: ffaf1 <fa-ml@ariis.it>
I think the question that should be asked is, how would one go about reaching a consensus about this issue?
The proposals process is about being able to mediate these concerns in a structured manner so if anyone wishes to gain a consensus then they have a means to achieve that. |
|
I updated with review commends and updated README.md. |
Co-authored-by: ffaf1 <fa-ml@ariis.it>
|
@ulysses4ever @Mikolaj Is there anywhere to advertise this more broadly? Or other people who you would like to get feedback on this structure from? |
|
@mpickering: I think we mentioned discourse, though I'm not 100% sure it's so widely interesting, though maybe as a pattern to follow in other Haskell projects? From the release checklist, the cabal-devel mailing list seems on spot and maybe Matrix (#haskell-tooling and #haskell-language-server). |
|
@mpickering: I think we mentioned discourse, though I'm not 100% sure it's so widely interesting, though maybe as a pattern to follow in other Haskell projects? From the release checklist, the cabal-devel mailing list seems on spot and maybe Matrix (#haskell-tooling and #haskell-language-server). Edit: and maybe mention it on our main Matrix channel again. |
|
@andreasabel , @andreabedini and @grayjay could be interested. |
|
I'd post it on Discourse anyway. |
|
FWIW I think Cabal has a lot of stakeholders (pretty much the entire Haskell community, in one way or another) so promoting awareness of this widely is a good idea. |
|
Thanks @ulysses4ever for offering to do that. Could you post a link here when you have made the topic? |
|
The proposal seems fine to me. One small bit I would add is that if a go/no-go for a proposal will be decided in a particular meeting, it would be good to advertise it somewhere beforehand. Otherwise we run the risk of stakeholders not attending the meeting, the meetings have been very thin lately, which is surprising given the amount of stakeholders of Cabal. I also think that Element probably does not have a wide enough reach, and maybe posting something on Discourse prior to the meetings would be better, I don't know. There is a side problem that was mentioned above, which is that Cabal has many stakeholders, possibly we don't even know about all of them, and it is unclear what are their requirements for Cabal. To add to the list above "Agda, Hackage builder, GHCJS, nix" there is also Stack, perhaps Bazel or Buck? I have wondered for a long time if we could somehow aggregate the requirements for features in these stakeholders, such as if no-one is using a particular feature, we could remove it from cabal. Honestly I have no idea of what parts of Cabal are used in the wild. For example you mention removing the v1 commands, but perhaps those are used by for example Nix? I don't know. |
|
There was an idea one time to post our meeting notes on discourse, maybe in a single running thread. Now that we have the Agenda (thank you again to all who contributed to establishing that and who extend and edit the agenda during the meetings), which becomes meeting notes after a meeting, this should be rather cheap to maintain. I this way the decisions will be published as well. Maybe we'd also outline or underline them. |
|
https://discourse.haskell.org/t/12393 also, I think it's a good idea to share info about the meetings / agenda on Discourse. But it's offtopic here perhaps... |
| In general, most changes do not require proposals, developers are trusted to | ||
| use their judgement about when seeking a broader consensus is necessary. |
There was a problem hiding this comment.
For contributors it would also be useful to know that they can still create a proposal for something that has been rejected ad-hoc by e.g. a single developer... as a means of forcing the democratic process as a last resort.
| ### 3. Decision Meeting | ||
|
|
||
| - The Cabal developers meeting is the forum for making decisions on proposals. | ||
| - The developers present at the meeting should reflect on the comments on a proposal and determine the [rough consensus](https://datatracker.ietf.org/doc/html/rfc7282) of the community. | ||
| The opinion of knowledgeable contributors regarding a particular subsystem is especially | ||
| important for the meeting to reach a decision. | ||
| - It is not necessarily expected that the participants of the meeting will offer a technical opinion. The discussion on the issue should provide enough context for a decision to be made. | ||
| - Those responsible for the proposal are encouraged to attend the developers meeting. | ||
| - There is a quorum of three developers at the meeting. | ||
| - If quorum is not reached for 4 consecutive meetings (8 weeks) whilst a proposal is due to be discussed, the proposal process is suspended and reviewed. |
There was a problem hiding this comment.
This feels a bit vague to me.
How exactly do cabal developers reach a decision? Do they vote? How?
I'd prefer to have a codified voting mechanism that is transparent to the outside world, similar to CLC.
Things being discussed in a video call meeting seems somewhat delicate to me as well for a decision making process. The proposer (or anyone else) can't respond to remarks, misunderstandings etc, unless those are public asynchronous comments on a github issue/PR. And it's intransparent, unless all involved parties have the time to attend.
What cabal developers do informally in video calls is up to them, but it isn't a good mechanism for a formal process.
There was a problem hiding this comment.
For the record, I recommended inviting the proposer to the meeting where the proposal would be discussed.
That said, I think informal is intended to be the point and a full formal mechanism like ghc-proposals or the CLC process is deliberately being avoided. It's not intended for that use case.
There was a problem hiding this comment.
Then I don't see how this is an improvement from the proposers point of view.
The benefit of such a proposal process are exactly the formalities:
- knowing precisely who will vote
- having a public record of the vote
- predictable and public interaction
Otherwise it seems to serve more Cabal devs as a means to demand "better PRs".
There was a problem hiding this comment.
It seems that we might have different expectations about what this proposal process is aiming to achieve. It’s intentionally more lightweight and informal than the GHC/CLC process. The goal here isn’t to set up a formal decision mechanism for external contributors, but rather to give existing Cabal developers a structured way to coordinate and record shared decisions.
Rather than voting, the intent is to look at the discussion and assess whether consensus has emerged. It’s more about making sure developers feel heard and aligned than about making purely technical judgments.
Some may find this informality imprecise, but for others it’s a better fit with how they already work on Cabal and less of a barrier to engagement than heavier processes. For me, what matters most is that active developers find the process useful and are willing to participate in it. If that ever stops being the case, then we should change the process.
There was a problem hiding this comment.
For the record, I recommended inviting the proposer to the meeting where the proposal would be discussed.
In CLC or GHC process, the proposer maker doesn't need to be involved synchronously, nor need to be then "alone in front of the committee". IMHO, inviting a proposer writer to a somewhat private meeting to be "interrogated" is a sure way to prevent (some) people from contributing.
As far as I can see, this "process" is a way to current Cabal developers to record design decisions. Whether an ADR (architecure decision record) log is used or something else, doesn't really matter.
I don't see this process a proposed to involve people not already contributing to Cabal to contribute. But I don't think that's the point. This text already includes "proposer writer is expected to implement it". This could backfire badly in situations like
- person opens an issue, with a potential solution
- Cabal developer responds with "this is potentially big change, we'll need a proposal for that, could you write it"
- limbo.
So TL;DR, this feels like an attempt to structure the Cabal development meeting more than anything else. If "proposals" needs to exist to make up an agenda, so be it.
There was a problem hiding this comment.
It's a public meeting, and in fact we're also discussing advertising them and their minutes more widely (e.g. on Discourse). And as @mpickering said, if this leads to your worry then the procedure will be changed.
|
|
||
| ## 4. The Decision | ||
|
|
||
| - A proposal is **accepted** if there is general agreement among active maintainers and contributors present at the meeting. |
There was a problem hiding this comment.
Who are the active maintainers who partake in the decision? Are they written down somewhere? How to become an active maintainer?
There was a problem hiding this comment.
You become an active maintainer by participating in issues, making PRs, commenting on proposals and so on, like normal, the currency of an open source project is the contribution.
At the core of the proposed process is the idea that it is the developers who are most actively engaged in the day-to-day work are those with the ability to make impactful decisions.
There was a problem hiding this comment.
I faced a problem that I was engaged in day-to-day work, but I explicitly didn't want to make impactful decisions, but would rather preferred someone else to take the burden of responsibility of decision making.
I feel that current Cabal team actually lacks people who could write their name on the list "we make the decisions, we'll respond to any positive or negative feedback". In other words, leadership.
I kind of want to see the list of names. I want to know there are people who eventually will (and must?) make a decision.
- If quorum is not reached for 4 consecutive meetings (8 weeks) whilst a proposal is due to be discussed, the proposal process is suspended and reviewed.
The process can be stuck. There is no way to force progress on difficult issues.
There was a problem hiding this comment.
I dropped in the suggestion of a quorum in part to address this, and in fact my version included a strong suggestion to list such people. I'm not sure why @mpickering dropped that part; like you, I feel it is quite important. (For example, were @grayjay and I authorized to make decisions of this nature a few weeks ago when we were the only ones who showed up at the meeting?)
There was a problem hiding this comment.
(For example, were @grayjay and I authorized to make decisions of this nature a few weeks ago when we were the only ones who showed up at the meeting?)
Yes, you were. You were also authorized to postpone the decision if you were not sure about the wider consensus or for any other reason. If you misjudged any of this, you'd have opportunity to revert. Our processes are not supposed to guarantee infallibility nor immutability. Just best good faith effort.
I want to know there are people who eventually will (and must?) make a decision.
This is asking a lot of volunteer developers. Since contributing to cabal management is my part-time day job, I'm the last resort if all community processes fail, but in that case I rather sound an alarm and temporarily plug the worst holes, not become a one person orchestra. But just as with volunteers, where any commitment is "unless real live intervenes", mine is "as long as there's funding and maybe a short while longer, unless real live intervenes".
We could try a process where people are publicly nominated, publicly commit, etc., but that's raising the bar quite a lot for all concerned. This is partially orthogonal to this proposal, I think.
There was a problem hiding this comment.
I think it's not a bad idea to have a definition of "Cabal team" somewhere (github readme or the website or something): my general observation is that seeing some names on a project makes some people feel better about the project. The list may be composed very liberally and revised rarely.
Having such a list will alleviate some of the worries about the vague process.
| the [proposal process](proposals.md) can be used. Proposals are discussed in | ||
| the [`cabal-proposals`](http://github.com/haskell/cabal-proposals) repository. | ||
| When does a change require a proposal? |
There was a problem hiding this comment.
Very much appreciated that a reasonable approach to proposals is suggested here, unlike the bureaucratic processes for GHC and base...
There was a problem hiding this comment.
Thanks @andreasabel 👍
The cabal developers are interested to adopt a proposal process, the details are found in the
proposals.mdfile. I am proposing this change but the process has been shaped alongside other cabal developers, it is something I want to work on together with people through this PR.The process is designed to make developers feel empowered to make decisions.
Overall, we hope that this will allow developers to move the cabal project forward.
cc @Mikolaj @ulysses4ever @geekosaur @ffaf1 as the attendees of the meeting last night who expressed an opinion about this.
Rendered link: https://github.com/haskell/cabal/blob/950adfddd2541a355a4cd52ef42b7ece435d8513/proposals.md