Comment by haberman
11 days ago
Lately I'm seeing more and more value in writing down expectations explicitly, especially when people's implicit assumptions about those expectations diverge.
The linked gist seems to mostly be describing a misalignment between the expectations of the project owners and its users. I don't know the context, but it seems to have been written in frustration. It does articulate a set of expectations, but it is written in a defensive and exasperated tone.
If I found myself in a situation like that today, I would write a CONTRIBUTING.md file in the project root that describes my expectations (eg. PRs are / are not welcome, decisions about the project are made in X fashion, etc.) in a dispassionate way. If users expressed expectations that were misaligned with my intentions, I would simply point them to CONTRIBUTING.md and close off the discussion. I would try to take this step long before I had the level of frustration that is expressed in the gist.
I don't say this to criticize the linked post; I've only recently come to this understanding. But it seems like a healthier approach than to let frustration and resentment grow over time.
Agreed, TFA is a good example of how to write down expectations explicitly.
But as far as dinging Hickey for the fact that he eventually needed to write bluntly? I'm not feeling that at all. Some folks feel that open-source teams owe them free work. No amount of explanation will change many of those folks' minds. They understand the arguments. They just don't agree.
> he eventually needed to write bluntly
Is there a history of that here? Were there earlier clear statements of expectations (like CONTRIBUTING.md) that expressed the same expectations, but in a straightforward way, that people just willfully disregarded?
I don't mean to "ding" anybody, I mostly just felt bad that things had gotten to the point where the author was so frustrated. I completely agree that project owners have the right to set whatever terms they want, and should not suffer grief for standing by those terms.
I don't remember the exact situation, but I think this relates to this:
Clojure core was sent a set of patches that were supposed to improve performance of immutable data structures but were provided without much consideration of the bigger picture or over optimized for a specific use case.
There's a Reddit thread which provides a bit more detail so excuse me if I got some of it wrong: https://www.reddit.com/r/Clojure/comments/a01hu2/the_current...
*Edit* - actually this a better summary: https://old.reddit.com/r/Clojure/comments/a0pjq9/rich_hickey...
1 reply →
> Is there a history of that here?
I have been maintaining not-super-successful open source projects, and I've had to deal with entitled jerks. Every. Single. Time. I am totally convinced that any successful open source project sees a lot more of that.
> Were there earlier clear statements of expectations (like CONTRIBUTING.md) that expressed the same expectations, but in a straightforward way, that people just willfully disregarded?
IMO it's not needed. I don't have to clearly state expectations: I open source my code, you're entitled to exactly what the licence says. The CONTRIBUTING.md is more some kind of documentation, trying to avoid having to repeat the same thing for each contribution. But I don't think anyone would write "we commit to providing free support and free work someone asks for it" in there :-).
Someone once said: Abuse and expectations erode a culture of cooperation.
I am currently seeing this in real time at $work. A flagship product has been placed onto the platform we're building, and the entire sales/marketing/project culture is not adjusting at all. People are pushy, abusive, communicate badly and escalate everything to the C-Level. As a result, we in Platform Engineering are now channeling our inner old school sysadmins, put up support processes, tickets, rules, expectations and everything else can go die in a ditch.
Everyone suffers now, but we need to do this to manage our own sanity.
And to me at least, it feels like this is happening with a lot of OSS infrastructure projects. People are getting really pushy and pissy about something they need from these projects. I'd rather talk to my boss to setup a PR for something we need (and I'm decently successful with those), but other people are just very angry that OSS projects don't fullfil their very niche need.
And then you get into this area of anger, frustration, putting down boundaries that are harmful but necessary to the maintainers.
Even just "sending them to the CONTRIBUTING.md". Just with a few people at work, we are sending out dozens of reminders about the documentation and how to work with us effectively per week to just a few people. This is not something I would do on my free time for just a singular day and the pain-curbing salary is also looking slim so far.
Furthermore, writing down the contract calmly, as part of a plan, can avoid having to bang it out in frustration and leaving a bad taste.
> I don't say this to criticize the linked post
What you have written is obviously a criticism of the linked post.
If I'm criticizing the linked post, then I'm also criticizing myself, because I could easily imagine having written it.
I think some might get the impression that you're complaining about Hickey's tone. Perhaps your emotional terms "frustration," "defensive," and "exasperated" may be the reason.
4 replies →