haskell
First draft of the cabal-proposals process
The cabal developers are interested to adopt a proposal process, the details are found in the proposals.md file. 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.
- 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.
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
A discussion issue for this topic: https://github.com/haskell/cabal/discussions/11007
Since the draft references v1 commands, I am reading #10262.
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.
Since the draft references
v1commands, I am reading #10262.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.
I think the question that should be asked is, how would one go about reaching a consensus about this issue?
v2-commands have been the primary way to use cabal for around 10 years now?v1-commands are no longer maintainer or developed.- It is never going to be universally agreed to remove the feature.
v2-commands are not designed to, intended to, nor will ever, support everything thatv1-was capable of doing.
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.
@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.
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...
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.
-
Any in-sync meetings work only as long as all participants sit around the pond. It's a huge challenge for anyone farther away.
-
Be aware that unless you keep meeting minutes expertly and meticulously and publish them without much editing, you will be perceived as a cabal. Written processes are much more transparent for the community and allow to achieve higher legitimacy.
-
Any proposal process, especially with certain service level agreements, needs a secretary / a chair.
-
I'd keep the same repo instead of setting up a different one. You can store proposals under
proposals/, that's it. It's easier to link code and crossreferences from the same namespace. -
I'm skeptical about the stated service level. Two weeks are not that much time and important stakeholders can easily be away for vacation or whatever.
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.
- This is how decision making already takes place in the Cabal project. The process is designed to fit into existing workflows and existing developers don't want to change that.
- The "decision-making" takes place by discussion on the proposal, it is transparent and evident for anyone in any time zone to see and participate in. The purpose of the meeting is to assess the decision that the community has come to on the proposal, evaluate whether important points have been considered from the right experts around the globe. If the developers at the meeting routinely misassess the consensus behind a proposal, then that would be concerning, but also a moment to reflect on if the process is working.
- Having this process allows any developer to interact with the existing decision making process, which was previously impossible unless you attended the meeting. That seems like an improvement to me after working on some larger cabal patches and changes which required attending this meeting to build consensus around.
@Bodigrim Yes, two weeks may certainly be too short, something which can be amended easily in future. It is something important to consider certainly.
The purpose of the meeting is to assess the decision that the community has come to on the proposal, evaluate whether important points have been considered from the right experts around the globe. If the developers at the meeting routinely misassess the consensus behind a proposal,
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?
Having this process allows any developer to interact with the existing decision making process, which was previously impossible unless you attended the (past?) meeting.
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"?
Do I understand right. Currently decisions are made in the meeting.
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.
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.
At the latest cabal developers meeting it was decided to move forwards with this process and to see how it goes. Therefore I'll merge this PR and we can reassess how well things are working after there have been a few proposals.