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 <[email protected]>
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 <[email protected]>
|
@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.
proposals.md
Outdated
| ### 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.
Cabal is ubiquitous as mentioned above. So how about baking in ad feature into cabal announcing events during successful build at some probability, based on features used in cabal projects to target specific users eg ghcjs.
There was a problem hiding this comment.
Nagging users is a no-no, I would not like it if other tools did just that.
There are more appropriate channels (Discourse, social media, if the need arises even release notes).
There was a problem hiding this comment.
No is to rigid rule. User can disable the feature. By default it can be active on weekends and for projects not published on hackage. This way target group is hobbyist which might have time for community and valuable feedback
There was a problem hiding this comment.
For me, what matters most is that active developers find the process useful and are willing to participate in it.
This is exactly what I think is problematic. This process mainly serves cabal developers, not contributors.
I think contributors (and users to an extent) care about:
- transparency
- good (and swift) decision making processes
- clear public and asynchronous communication
I'm worried the proposal may in fact hurt contributions, because all I see is that I need to do more work as a contributor, but don't get much in return.
However, I think it's on the right track. Stronger formalities don't mean the process isn't lightweight anymore. The main thing that makes it lightweight is that not everything requires a proposal... either developers or contributors would need to call for the proposal process: that's good.
There was a problem hiding this comment.
I think if we disagree about that principle then we just have to disagree about it. I'm not interested to design a process which active developers don't wish to participate in.
|
|
||
| ## 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.
It is very disempowering to be told by higher forces what you can and can't do, especially when most contributors are volunteers, why would you bother?
I'm a bit confused about this statement.
Isn't that exactly what the "inner circle" of cabal devs now is going to do with "collaborators" who are not part of the inner circle?
They are all volunteers.
There was a problem hiding this comment.
I think another way to put it, is that I agree with the GHCup philosophy about decision making in projects: "I do not believe in people making decisions over projects they are barely involved in.".
There was a problem hiding this comment.
Isn't that exactly what the "inner circle" of cabal devs now is going to do with "collaborators" who are not part of the inner circle?
No, I think you are misunderstanding the process here. I have explained in this comment - #11006 (comment)
There was a problem hiding this comment.
I think another way to put it, is that I agree with the GHCup philosophy about decision making in projects: "I do not believe in people making decisions over projects they are barely involved in.".
GHCup follows a BDFL governance model, not an open governance model.
What model does cabal follow?
And I still don't understand what contributors get out of the proposal process. So far it seems to only serve cabal developers, is that right? If that's the case, then that's fair, but it's important to know for the discussion.
There was a problem hiding this comment.
@geekosaur I added a quorum clause based on your suggestion, did you intend for me to write something different?
I said I wanted a quorum of people authorized to make decisions on behalf of Cabal, and those people would need to be chosen on the Cabal devs side. This is one reason I also said at the time that we currently run things just a little too loosely for the proposal to work as is.
| 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 👍
|
Let me drop a few notes, just reflecting on the experience of running CLC proposal process for several years, but please do feel free to ignore. You do you and have a right to set up processes as you like them.
|
|
I want to highlight the importance of point 1 and 2 by @Bodigrim: I'm GMT+8 and join European time meetings only in exceptional circumstances. Meetings with North America require me to stay up until midnight or later. So if you want people from Asia and NA to participate, you're in a tough spot. Synchronous meetings are a great way to handle management stuff (prioritization, call for help, etc.), but are a rather poor mechanism for decision making processes in an open source community. It truly makes some of us feel that cabal prefers to operate "behind closed doors", even if that's likely not the intention. |
|
@hasufell @Bodigrim I think you are raising an important point about the meeting but there are a few points to consider.
@Bodigrim Yes, two weeks may certainly be too short, something which can be amended easily in future. It is something important to consider certainly. |
So "the (future) meeting" doesn't actually make any decisions, but only *assesses if consensus is reached on the discussion on GitHub? How that would help Cabal developers to feel empowered to make decisions?
Do I understand right. Currently decisions are made in the meeting. This change suggests that consensus is to be achieved in GitHub discussion and in the future the meeting is a "rubber stamp"? |
I think currently design decisions are mostly made in issues and (prototype) PRs. Or, as it happens, a decision is not arrived at in the PR nor anywhere else, but the PR is the main point of contact in case somebody has a new idea how to reach consensus (BTW, that's always both consensus about design and about who is going to implement it; just one of these is usually a waste of somebody's or everybody's time). The meeting is another point of contact. |
|
One thing that occurred to me is that we're not currently using GitHub Discussions, so they would be available as a distinct discussion area for proposals. |
|
My understanding is that the proposed process largely codifies the existing practice (or an idealized version of it). That's a reasonable improvement over status quo, giving potential contributors a better picture of what to expect. Some comments here voice concerns that the existing practice is fundamentally wanting (which to be honest is something I can subscribe to), but I don't think they can be resolved within the available budget. I think it's better for Cabal team to codify a process they have bandwidth and capacity for rather than to be forced into a schema they lack resources to execute. |
Thanks for your very reasonable and considered comment @Bodigrim. I can understand that you and others would prefer some tweaks to the process but it is appreciated that you can see that it's a scheme which would be appropriate for this situation. |
| ## Backwards Compatibility / Migration | ||
|
|
||
| Does this change affect backwards compatibility? What migration path is needed? | ||
|
|
There was a problem hiding this comment.
| ## Interested parties | |
| Who are the interested parties in the broader Haskell community? Have you contacted them? |
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