Dear haskellers,
Were you ever held back from proposing changes to Cabal in the past? What can we do to fix it?
Matthew Pickering suggests a new proposal process for Cabal. The idea is to have a more structured way to introduce Big Changes™ to the critical piece of Haskell infrastructure that Cabal is.
Please, check it out and share your thoughts on the discussion thread:
Can you elaborate why you want community input for this?
From the brief discussion on the PR it seems that:
To quote from the PR comments:
- 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.
I don’t think cabal developers are obliged to gather community input on this. But I’m a bit confused about the discussion. If you just want to codify existing practice, it’s enough to discuss it internally and update the contribution guidelines.
Not OP. It seems to me the benefits to contributors are quite clear, and the main point of this proposal.
Contributors will have a codified forum where to present, discuss and gather comments on their proposals, before implementation. At the end of the process — which has time limits — they will receive a yes, no, or further changes required response.
This provides clarity and is respectful of both contributors’ time and efforts.
Right. The “we’ll make a decision in X weeks” seems to be the only thing relevant for contributors. Everything else stays mostly as is.
But the proposal doesn’t say how any of this is achieved. Given that I’ve waited in several instances for 1+ year for an answer, I’m curious how this is gonna work without a more formal process (which was dismissed in the PR), more resources (in terms of decision makers) or simply better leadership.
Can you elaborate why you want community input for this?
In short, we post it in the “Announcement” section, which means we not only want input, but we also want to announce this to a wider audience than very few people who get on Cabal video calls or track every discussion on GitHub. or hang out on Matrix. Judging by the engagement so far (likes and comments on the thread), people are interested. Thank you for contributing your point of view, by the way.
I’m a bit confused about the discussion. If you just want to codify existing practice, it’s enough to discuss it internally
The reason we want a broader attention is this. Cabal repository regularly receives contributions in the form of PR, without a design document that explains what the problem is, what solutions have been considered, what solution has been adopted, and why it is the right solution for the problem; sometimes, there’s no issue even. This is a problem for Cabal maintainers. The new process (and the announcement) tries to improve the state of things.
I’d not fixate on “codify the existing process” thing — although it’s mentioned in the thread, I personally think it’s a red herring. The new process does have two new components.
These two points concern everyone who wants to push significant changes in Cabal, that’s why we post it here.
I just have to repeat my point: what do contributors get out of this.
It seems purely like an attempt to improve “internal organization”.
As such, I find the communication regarding this topic somewhat misleading.
What feedback do you want from us? I don’t feel it has been appreciated so far. Do you want me to demonstrate the deficiencies I experienced in detail?
I guess every proposal process is also an attempt to improve “internal” organization. But it has consequences for contributors that we wanted people to be aware of.
What feedback do you want from us?
I’m sorry but I can’t answer this question. We already had some great feedback after posting here, and we certainly hope to get more. I just don’t see a way to specify “what” feedback.
Given how tightly resource constrained cabal development is, relying heavily on volunteers, have you considered:
Given the comments in the PR (e.g. about synchronous meetings/not caring about timezone differences) I am a bit worried about the situation and it still seems to me that development isn’t particularly “open”.
It doesn’t have to be, but there’s no BDFL and the project is likely too large and historical for it anyway. So what is the strategy for governance and maintaining a healthy contribution experience?
…for example:
So what happened - did anything improve as a result?
Yes, you can read about the new Cabal Hooks architecture designed to replace custom builds here: An introduction to Cabal Hooks for package authors - Well-Typed: The Haskell Consultants
To be fair to @atravers, that’s only one aspect of the Sovereign Tech Fund proposal. The other, perhaps more relevant, aspect was/is:
- Maintainer time for tasks such as making releases, keeping CI up and running, reviewing and landing volunteer contributions, and assisting users of Cabal and
cabal-install. This is especially welcome as Cabal has been lacking maintainer funding for some time.
[emphasis mine]
I support having a proposal process. As an occasional contributor to Cabal, I would love to have one single place I could go to read up on past or current decisions. It would even make it easier to effect the governance changes some people would like to see, if those could be explicitly put in scope.