Clarify the decision making process

[hasufell]

I'm somewhat reluctant in participating in the proposal process, because I do not understand the decision making process.

The Readme says:

A proposal is accepted if there is general agreement among active maintainers and contributors present at the meeting.
A proposal is rejected if consensus cannot be reached or the developers do not wish to pursue the direction of the proposal.

The document mixes different terminologies:

• active maintainers
• contributors
• developers

"Maintainers" seems to be defined in this recent PR. It's unclear who contributors and developers are, however.

This means I have no idea who I have to convince and the set of people who make the decision may change every other week. I don't think that's a reasonable situation from a proposers point of view. Nor do I think it's healthy for cabal as a whole, which lacks leadership and vision.

It's also not clear how people can participate in the decision making process.

[ffaf1]

Wording can always be improved, but this is clear

cabal-proposals/README.md

Lines 83 to 85 in 37f681e

	- 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.

[hasufell]

Who are "The developers"?

[ffaf1]

I could answer with “people crontibuting to cabal, either regularly or with expertise in a specific subsystem”, but that is not the point, is it?

The task of the meeting is to assess consensus, which should already be there in the proposal PR.

The opinion of knowledgeable contributors regarding a particular subsystem is especially important for the meeting to reach a decision.

↑ The people you should convince are there.

[hasufell]

So if I understand correctly:

• there is no list of developers
• there is no list of people contributing to cabal
• there is no list of experts regarding subsystems
• there is no committee that clearly votes on a proposal

So the proposer has no idea with whom to engage and who to convince.

[ffaf1]

Matthew, who created this repository and the proposal process, is currently on vacation. I feel this discussion will be more productive when he will read this thread an offer his thoughts. Il 03 settembre 2025 alle 04:07 Julian Ospald ha scritto:

…

hasufell left a comment (haskell/cabal-proposals#3) So if I understand correctly: - there is no list of developers - there is no list of people contributing to cabal - there is no list of experts regarding subsystems - there is no committee that clearly votes on a proposal So the proposer has no idea with whom to engage and who to convince. -- Reply to this email directly or view it on GitHub: #3 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[mpickering]

Hi Julian,

Sorry to hear that you feel reluctant to write a proposal, you have some ideas which would be interesting to pursue in this format.

When you write a proposal your tasks is to demonstrate that there is consensus around the change.

How can you do this?

• By identifying the stakeholders who will be impacted by a change and soliciting their opinion.
• By responding to feedback and comments from people who comment on the proposal.
• By inviting contribution from experts in the area who can participate in an "as-required" capacity rather than a "always-engaged" maintainer capacity.

It could be useful as you point out to provide a document which suggests who stakeholders in each subsystem are. I think we are just getting started here so these ideas are useful.

This process is also collaborative, the maintainers and participants in the process can help to identify those who are affected and to gather feedback from experts.

Once you believe consensus is established, then the people attending the cabal developers meeting will then perform a check, to see that they agree with you that consensus has been reached and can accept a proposal. If a developer has a strenuous object to the proposal, that should already have been communicated in the discussion on the proposal rather than reserved for the final meeting.

Does that help you out? If you need some help writing a proposal then I am happy to assist.

[hasufell]

By identifying the stakeholders who will be impacted by a change and soliciting their opinion.

This is unreasonable I'm afraid. You're basically telling me that:

• the proposer has to guess who to convince
• it's unclear who actually makes the decision... it appears that cabal developers just kind of vibe-check the proposal

My opinion is that this is inappropriate for a core library. While I have no intention to dictate the process, I think #2 has also shown that there might be a problem with the maintenance state. So I'll repeat it here: if cabal maintainers can't review PRs or comment on the technical merits of proposals, then I think you have an obligation to recruit more maintainers.

[ffaf1]

This is unreasonable I'm afraid. You're basically telling me that:

• the proposer has to guess who to convince

Something as simple as git annotate and checking the relevant PRs would give a good idea of who does what. It helps with familiarising with the codebase and the people who have written it, too.

If that fails, Cabal provides a number of forums where to ask for help in identifying stakeholders (and on other dev matters):

1. the mailing list;
2. the Matrix room;
3. the issue tracker.

All of these venues are listed in CONTRIBUTING.md.
You can also ask in the PR, too.

To contribute to any Open Source project, you need both technical skills and a modicum of social ones.
I would say asking questions is normal, expected and encouraged in any organisation/firm which is not a one-man project.

• it's unclear who actually makes the decision... it appears that cabal developers just kind of vibe-check the proposal

README.md states it plainly:

cabal-proposals/README.md

Lines 82 to 88 in 37f681e

	- 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.
	- 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.

[hasufell]

I think we're talking past each other.

[mpickering]

The proposals process is intended as a way for Cabal developers to draw on external expertise from people who may not wish to be involved in day-to-day maintenance. There are many people in the community whose opinion is valuable when making changes to the core ecosystem.

It seems that you’ve decided not to participate in the process at this point, which is completely fine. You have a lot of expertise to offer, though, and we’d be glad to see you contribute in the future, whether through your own proposals or by lending technical input on proposals from others.

It has definitely been useful to clarify these points that you brought up, so that you and other people can also decide if the process is for them or not.