On helping clojure.core


#21

Also, the point of making a thread here is to have people weigh in over the course of days, in a forum that’s discoverable by google and can be linked to quite easily. I think Alex’s post that shared some context and links etc is very helpful for everyone.


#22

@andy.fingerhut said:

They made a decision that included that feedback.

No they didn’t, as the post from Rich that you referenced above says itself. I’ll even quote it for you:

I prefer patches. I understand some people don’t. Can’t we just agree to disagree?

This literally says “I’ve heard the community’s feedback, disagree with it, and as BDFL I’m making a unilateral call to ignore it” (as is the core team’s right - I’m not disputing that at all). However it is rather disingenuous to say that that decision “includes” that feedback.

At least Rich seemed to understand the consequences of this, when he wrote:

I respect the fact that people disagree, and they might decide not to participate as a result.

It’s therefore surprising to me that there’s so much sturm und drang from the core team each time this issue resurfaces - this is exactly what would be expected from a situation where community feedback was not factored into the decision.


#23

Please, let’s not use this topic to judge – just facts.

Well, that didn’t last long.

Seems we’ve strayed far from “allow people to help clojure.core in areas where they want and can take help.” Does the OP consider this goal met?


#24

So when person A pays attention to what person B says, A always ends up agreeing with B? I don’t think that’s how it works.


#25

Sorry, I’m not helping enough with the original goal, either. Read Alex Miller’s reply, and my first one. I’ll invite pmonks to reply privately if he wants to carry on a conversation on whatever that turns into.


#26

@andy.fingerhut wrote:

So when person A pays attention to what person B says, A always ends up agreeing with B? I don’t think that’s how it works.

Nice straw man you’ve created there, but I’m not particularly interested in debating it with you. Please reread some of my earlier replies to understand my position.

I’ll invite pmonks to reply privately if he wants to carry on a conversation on whatever that turns into.

Happy to, though I haven’t found a private message capability on this platform yet. Can you give me a pointer?

Alternatively, and in the spirit of open source, we can continue openly in another thread. I’m certainly aware that this ratholing around PRs vs patches-in-JIRA has sucked the oxygen out of @orestis’ post, and that wasn’t my intent (as is pretty self evident in my first reply).


#27

I think everyone here actually agrees with each other.

We’re not all building Clojure together. That’s not currently the kind of project Clojure is. Rich Hickey and maybe some of his close associates are building Clojure. They’re doing it the way they want. It’s their project, they put in the work and effort, and they’re responsible for its successes and failures.

I think this part is pretty clear. It’s actually good to understand that, because I know some people are interested in being part of the development of a language, they’d like to have input and contribute to the decision and planning, and for that, Clojure is currently the wrong project. I’d suggest to people who are looking for that to look at Rust, it has very much adopted a full on community driven process, for better or worse.

That said, Clojure is still a very friendly and welcoming place, and the core team cares about the community, and wants people to use and enjoy using Clojure. So if you’re someone simply looking for a programming language to use, Clojure is a great place for you. You will feel supported and listened too.

Maybe an analogy for this is that with Clojure, you are a customer, and the core team provides you with a product and support for that product. You are not a team member working with the core team on the product. Obiously, in this case, the product is free and the support is voluntary.

I think this is a good thing to be open about, so that we give people the right expectations coming in.

Now, as a community, there’s a lot we can add to Clojure, with tooling, library, support, training, conferences, bug reporting, voting on issues, etc.

Also, you can try and contribute to Clojure core, provide patches, and see if the core team is persuaded by its value. Just be sure not to expect that you are part of that decision.


#28

@didibus I agree with pretty much all of what you’ve said, except for one thing:

As I’ve said several times in this thread now, and at the risk of sounding like a broken record, the mere fact that this same topic of conversation resurfaces in the community every so often is pretty compelling evidence that this is not clear to a lot of community members.

I’ve also previously proposed what one solution might be: “I just think it would be beneficial for everyone if that policy [i.e. that we’re not all building Clojure together] was stated explicitly and unambiguously”. Perhaps this page would be an appropriate place to clarify the policy?


#29

And there is an issue open to add a note to that effect to the Clojure site somewhere, here: https://github.com/clojure/clojure-site/issues/327


#30

I am working on moving over some of the community pages from the old wiki and adding some additional content to clarify things and or how to help (of which there are many!).


#31

Re “we are not building Clojure together”, I think this is an extreme and disingenuous depiction of how things work. We are interested in community feedback, suggestions, patches, etc even if that interaction has a different shape than other open source projects. Here’s a list of all the tickets in Clojure 1.10 for example:

There are a bunch of tickets here both filed by the community and fixed by the community. We knocked off some of the highest voted defects and some highly voted enhancement/features in this release, again based on community feedback in the form of votes. We do this in every release.

So, you (the greater community) ARE part of the decision about where we pay attention, and we regularly pay attention to the things people are voting on, talking about repeatedly in Clojure forums, or having significant issues with. Sometimes those are rapidly addressed, sometimes it’s a slow burn. Good tickets and clean patches definitely make things faster.

There are plenty of issues with how all this works, and ways things could be better. We regularly talk about it, and we’re talking more about it now. We’re going to try make the process clearer, make some decisions more transparent, and be more explicit about how we take feedback.

That said, I think if you take a big step back, we are not seeing instability between releases, or critical production breakages that prevent people from doing their work, etc. Rather we see a measured drumbeat of fixes and features both big and small. The idea that the sky is falling in some way seems way overblown.


#32

Re “won’t fix” tickets, here’s a reverse date-ordered list of declined tickets:

https://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CLJ+AND+status+%3D+Closed+and+resolution++%3D+Declined+and+issuetype+in+(Enhancement%2C+Feature)+ORDER+BY+updated+desc

There are 18 from 2018 and many of those were actually closed by the original poster, subsumed into other work, misconceptions about how something worked, or a few were actually very old and reopened only because they had collected a spam comment. In reality, there are probably only a handful of real suggestions that were declined. I realize that one of those (https://dev.clojure.org/jira/browse/CLJ-2253) was yours and you disagree with my decision on it. I really don’t want into it again - everything I have to say about it is in the comments on the ticket, others can judge for themselves.

Overall, enhancement tickets are declined relatively rarely. The downside of declining something that should have been accepted is low - we don’t get that enhancement, but maybe its need becomes more obvious later if it’s asked for or filed many times, and then we look at it again. The downside of accepting something that we later regret is much much higher. As they say, no is temporary, yes is forever. We are unapologetically conservative about those choices.

It may be helpful to enumerate somewhere the axes on which I triage enhancements and make decisions, and I think that’s a reasonable doc request.


#33

Thanks for this update, that is great to hear. This kind of messaging really helps.


#34

I’d like to note that Rust’s largely open process has its issues, as described by one of the team members building the async/await feature. It’s tough to coordinate design. It’s really tough when the group of people who discuss the design is huge.