Should every member provide a manifesto?

[hasufell]

Hi CLC colleagues.

I've had a long discussion with @tomjaguarpaw about this. There are two motivations to this:

1. allow users to judge their success chances prior to a proposal
2. possibly come up with a joint non-binding baseline of principles that all members agree on (or not)

The first step may be that every member just publishes a manifesto and we collect them here and maybe discuss them internally to see whether there's any point in attempting to tackle point 2.

It may also serve contributors to challenge a CLC member's prior-vote opinion by pointing out inconsistencies of their opinion regarding their manifesto. Maybe no one will ever read them, but I found it a good exercise for myself regardless, thinking about what I actually expect of base.

It may be useful to loosely follow a similar structure:

• purpose of base
• opinion on breaking changes and deprecation
• other topics such as performance, totality, expectations of contributions, etc.

---

Here's mine: https://gist.github.com/hasufell/d9d33cc44f65163f493e09da311ef6a7

[chshersh]

I would encourage everyone to reflect about what they expect from CLC and how do they view changes in base, and I would appreciate everyone being transparent about this 🙌🏻 I myself don't mind writing my manifesto.

However, I think that coming with objective principles is more important here, and would pay off significantly.

I view CLC as volunteers who execute the CLC function. Ideally, personal views and opinions shouldn't matter for judging whether to accept a proposal or not. I really don't want CLC to become a place whether being accepted or rejected depends on current people in CLC and your personal relationship with those people.

For example, I opened a proposal in the past that was rejected. Now, since CLC has many new members, I can reopen this proposal and ask for the vote again (considering that I myself can vote in favour). But as much as I wanted to see this proposal accepted, I would be sad if it the acceptance depended on personal views of a small group of people and not on the general direction for the Haskell standard library.

• Add the '|>' pipe operator #78

---

To steer the conversation towards create specific actions, I propose to create a document, describing how likely the proposal to be accepted based on several criteria. Specifically,

1. Is it a breaking change or not? (and maybe go into more details on which changes are "more breaking")
2. Does it fix a bug? (and how severe this bug is?)
3. Does it improve performance?
4. Is this function / data type / typeclass already available in another package and how popular this package is?

and so on.

Let's say, it's a scoring system from 0 to 10 total.

• If the score is <4, the proposal is unlikely to be accepted.
• If the score is >8, the proposal is likely to be accepted.
• Everything else needs discussion and will be considered on case-by-case basis.

---

For context, the previous similar conversation:

• Decide on core principles against which to judge breaking changes #12

[hasufell]

@chshersh fyi... much of my manifesto is based on my response in your core principles thread: #12 (comment)

Whether we'll be able to agree on such principles remains to be seen. I don't think it's a prerequisite for a functioning committee, though. But it may be worthwhile to try to achieve it (for the sake of base itself).

But even if we do, personal opinion will always play a role, because judging impact, consequences, user experience etc. are not "pure functions".

[chshersh]

@hasufell Sure, whatever system we came up with won't be able to answer all questions precisely, so CLC is still needed.

What I was trying to say, answering your idea to give users an estimation of whether their changes will be accepted or not, that working collaboratively on CLC guiding principles would be a more efficient way to spend time than writing a personal manifesto and asking CLC proposal authors to read individual preferences of each CLC member.

[hasufell]

that working collaboratively on CLC guiding principles would be a more efficient way to spend time than writing a personal manifesto

Each member writing a manifesto is the prerequisite to us understanding whether there's any common ground. So I consider that the start of such collaboration.

[phadej]

Is CLC a group of politicians or civil servants / officials?

Please figure out. That will directly affect my willingness to interact with CLC.

FWIW, @hasufell stance of not accepting any breaking change doesn't motivate me to submit any non-breaking additions either - How can I know I got them right from the first time? How adding plenty of small helpers now won't create a naming mess, which would require breaking renaming to be clarified? Or should I just rush to submit proposals adding everything I need now, and the cleaning up will be someone elses problem?

[hasufell]

@phadej this thread is about understanding whether we want to communicate our opinions on base as CLC individuals better. Members may simply not want to do that.

In case everyone agrees, though, I think we might make progress on understanding how much common ground there is and whether deriving common principles might be a viable strategy.

Does that not explain the intention?

[phadej]

I'd welcome you deriving common principles, and if you fail to do so, then... well, you may just disband CLC then.

[gbaz]

The above comment is not helpful. A committee need not agree on everything to reach decisions, as long as decisions are not made solely by total consensus.

[phadej]

@gbaz you are understanding me wrong.

For example, if committee cannot agree on how they approach breaking changes, the hot topic right now, then they could just say to people to not propose breaking changes to begin with.

The current README can be understood as that as long as I make impact assessment, (the change doesn't break literally everything), and I make a patches then the fact that a change break something is not a blocker. But reading @hasufell's manifesto, it seems like it breaking changes are virtually no go (please correct me if I understood wrong), and quite a hard one.

[konsumlamm]

But reading @hasufell's manifesto, it seems like it breaking changes are virtually no go (please correct me if I understood wrong), and quite a hard one.

That's how he personally wants to vote, what's the problem with making that clear? This is by no means a request for all CLC member to vote like this. Why should all CLC members have the same stance on breaking changes? I think the README.md/PROPOSALS.md should be understood as minimum requirements, it doesn't say that the proposal will be accepted if all points are fulfilled or that CLC members aren't allowed to have additional requirements.

[gbaz]

I agree with the above comment. If one person has very strict criteria, but the rest of the committee outvotes them, then those strict criteria are not blockers.

[phadej]

That's how he personally wants to vote, what's the problem with making that clear?

Nothing. That's great it's made clear. but if half of committee thinks so, it would better if it said out loud up front.

I'm very keen on hearing how each CLC commitee member and CLC committee as a whole thinks about breaking changes, and how they see we can make them happen...

... as if put bluntly, the breaking changes are the only ones worth proposing. Every non-breaking "addition" can be done in the "userland".

[tomjaguarpaw]

... as if put bluntly, the breaking changes are the only ones worth proposing. Every non-breaking "addition" can be done in the "userland".

I'm not sure what you mean. Here's a non-breaking "addition" you yourself proposed: #98 (comment). Was it "not worth proposing"?

[phadej]

@tomjaguarpaw that one is in preparation for the breaking change I'd like to propose later. (but useful already standalone).

[tomjaguarpaw]

I see. Can breaking changes also not be done in the "userland"? Naturally, they're then not really breaking, but it seems like if you want something to change functionality then you can get a similar outcome by just adding a new version with that functionality in the "userland".

[phadej]

Can breaking changes also not be done in the "userland"?

To some degree yes, but for example with type-classes - which are non-modular - it's virtually impossible.

An extreme example would be having an own version of Functor (or Bifunctor as in #91): you'd need to fork the whole ecosystem.

[Bodigrim]

The first step may be that every member just publishes a manifesto and we collect them here and maybe discuss them internally to see whether there's any point in attempting to tackle point 2.

Sorry, I'm not interested even in the first step. My experience is that in the open-source context such exercise is a time sink and does not actually save resources.

If I may suggest, new CLC members might wish to have more practice evaluating proposals before publishing a manifesto.

[emilypi]

If I may suggest, new CLC members might wish to have more practice evaluating proposals before publishing a manifesto.

To wit, engaging in good faith is the best solution to any problem raised in this thread. New CLC members especially. The process has been extremely successful in the past 2 years.

[parsonsmatt]

My manifesto:

I'll +1 anything that makes Haskell's core library situation better. Ergonomics, safety, and performance are big things for me.

I'll -1 anything that I think makes Haskell's core library situation worse. Breaking changes without helpful migration paths are probably the biggest problem. Fortunately, Haskell provides amazing tools for providing migration paths, and I'm happy to help proposal authors figure out a path forward that'll get that +1 from me.

I also totally understand not wanting to invest a ton of time and effort into a proposal only to get shot down. So I'm happy to talk things out at a very high level to figure out feasibility and whether it's worthwhile to make a proposal.

[hasufell]

If I may suggest, new CLC members might wish to have more practice evaluating proposals before publishing a manifesto.

I disagree, because this isn't so much about practice or experience, but intention and what we expect of base.

In other open source communities it's even standard to publish such manifesto before applying to the committee.

[hasufell]

@phadej you're misunderstanding maybe what a manifesto is? It's about principles and intentions.

One may have the intention to never break base API and then end up doing it over and over again due to there being good reasons or insufficient mechanics of GHC/Haskell to do otherwise.

These intricacies are maybe what I think @Bodigrim was hinting at, but IMO they are mostly irrelevant when talking about intentions and principles.

These are not meant to serve as an exhaustive decision tree, but as reference points.

E.g. regarding your concern about my specific manifesto (although I do not intend to discuss it in detail at this point, that's not the purpose of the thread, feel free to contact me privately): yes, if new additions have a very large design space and may need frequent iteration, then I think base is not a good place for that. You're right that typeclasses are special.

---

At any rate, 'base' as a standard library not having a proper "mission statement" seems like more than a documentation issue to me and I don't believe this will solve itself through experience and practice. I can see many benefits of trying to widen the consensus around principles.

However, there are always multiple modi operandi.

[maralorn]

This is obviously more about a social than a technical problem, so solutions are probably not trivially right or wrong.

Nevertheless, I want to caution a direction this suggestion is pointing to.

It is obvious that the individual opinions of committee members influence their decision. That is one of the reasons we have a committee in the first place, to balance views. Ignoring this fact makes us blind to reality.

On the other hand, emphasizing the personal stances of every member seems dangerous for the thought process. This might emphasize a world view where committee members stand on sides, where members potentially optimize for consistency of their positions in their judgements instead of correctness. Where we maybe even focus on sorting the committee into factions. (I am mainly writing this comment because I had the (far stretch) association that these manifestos could lead to “court packing” discussions.)

Again, all those things, e.g. in the context of breaking changes, might just be acknowledging reality. But I don’t think it is a healthy mindset to have when doing committee work. The committee should strive for processes which are objective and criteria based, which are made on a case-by-case basis by careful deliberation and not premade notions of the individual.

I totally see how this is a fuzzy and not very succinct dichotomy, and I don’t want to imply that the committee is erring on this or will definitely by erring in this direction. But I think there is something here which it makes sense to be careful of.

I would prefer processes which focus on forming consensus and objective criteria, instead of viewing the decisions of the committee as a deterministic function of the individual opinions of its members.

[hasufell]

On the other hand, emphasizing the personal stances of every member seems dangerous for the thought process. This might emphasize a world view where committee members stand on sides, where members potentially optimize for consistency of their positions in their judgements instead of correctness. Where we maybe even focus on sorting the committee into factions. (I am mainly writing this comment because I had the (far stretch) association that these manifestos could lead to “court packing” discussions.)

You've basically described the core processes of democratic public discourse:

1. forming opinions
2. voicing those opinions publicly
3. debating them
4. organizing groups and support around opinions

I'm not sure why you would find that to be a dangerous thought or why you make conclusions that this will somehow lead to worse or more biased decisions.

Quite the contrary. Through my private communication with other committee members I've already learned a lot about what kind of different opinions are possible and where they come from. And I will continue to do that.

Doing this in written form and in public is just one way. Given the course of this thread, I'm starting to think that private communication might indeed be more efficient, although less transparent.

Why I've been pushing this in its public form is easy to explain. It seems until recently, GHC HQ wasn't particularly aware that some parts of the community have a very different taste of breakage. Some of those revelations happened on this issue tracker, others on discourse. Can you imagine how this has gone unnoticed for maybe a decade? Because we're too focussed on concrete technical issues and have just started to discuss principles and goals as a community very recently (or so I feel).

Given that there are a lot of new members, I found this idea of sharing manifestos a great way to start and collaborate.

And I very vehemently oppose the idea that sharing thoughts and opinions is anything but positive (or at least informative).

[phadej]

@hasufell CLC is a self-elected body, there is barely anything democratic about that.

[hasufell]

@hasufell CLC is a self-elected body, there is barely anything democratic about that.

That's not what I was saying at all.

And I think this thread has no use anymore.