[0xbadcafebee]

Counterpoints:

- You are entitled to human decency. Maintainers don't get to be rude just because they run a project. This is a common thing in a lot of projects; maintainers have power, and this allows them to be rude without concern. Not ok.

- As a maintainer, if you publish your work as open source, you already acknowledge you are engaging with an entire community, culture, and ethos. We all know how it works: you put a license on your work that (often, but not always) says people need to share their changes. So those people may share their changes back to you, assuming you might want to integrate them. So you know this is going to happen... so you need to be prepared for that. That is a skill to learn.

- Since maintainers do owe basic human politeness, and they know people will be interacting with them, maintainers do owe this culture some form of communication of their intentions. If they don't want to take any changes, put that in CONTRIBUTING and turn off GH PRs. If they want to take changes, but no AI changes, put that in CONTRIBUTING. If they don't want to do support, turn off GH Issues. If they require a specific 10-point series of steps before they look at a PR or Issue, put that in CONTRIBUTING. It's on the user to read this document and follow it - but it's on you to create it, so they know how to interface with you.

Be polite, and tell people what you will and won't accept in CONTRIBUTING (and/or SUPPORT). Even if it's just "No contributing", "No support". (My personal issue: I spend hours working on preparing an Issue or PR to fix someone's project, and they ignore or close it without a word. Now I don't want to contribute to anything. This is bad for the open source community.)

[Linux-Fan]

> - Since maintainers do owe basic human politeness, and they know people will be interacting with them, maintainers do owe this culture some form of communication of their intentions. If they don't want to take any changes, put that in CONTRIBUTING and turn off GH PRs. If they want to take changes, but no AI changes, put that in CONTRIBUTING. If they don't want to do support, turn off GH Issues. If they require a specific 10-point series of steps before they look at a PR or Issue, put that in CONTRIBUTING. It's on the user to read this document and follow it - but it's on you to create it, so they know how to interface with you.

In general it is already in the license. Even permissive licenses like Expat have (in ALL CAPS no less)

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO [...]

There is zero need to indicate anything about CONTRIBUTING whatsoever because already it is clear that the developer already indicates that nothing can be taken for granted.

Of course it helps to be open about expectations.

I for instance don't put CONTRIBUTING instructions online but so far all of my stuff gets so little attention that I have received almost no feedback about my free software at all.

To me, this is perfectly OK and in line with the expectation that I for instance put my code online mostly for my own benefit. If it helps anyone else, all the better. But don't derive any more expectations from it because it's free...?

[palata]

> you put a license on your work that (often, but not always) says people need to share their changes

Permissive licences do not say that. Copyleft licences say that people need to share their changes with their users.

As a maintainer, if I choose a copyleft licence, it is to protect the users. If someone makes a product using my code, I want the user to be able to see that code even if it is modified. It does not mean at all that I am interested in adopting those changes in my repo. No need to be prepared for it.

> maintainers do owe this culture some form of communication of their intentions

I disagree. I already give you my work for free, that's something. I don't see why I should get out of my way to communicate my intentions. When in doubt, you are free to contact me (e.g. open an issue) and ask. And I am free to not answer.

> My personal issue: I spend hours working on preparing an Issue or PR to fix someone's project, and they ignore or close it without a word. Now I don't want to contribute to anything. This is bad for the open source community.

Happened to me as well, and it is very frustrating. But that's on me, I should have asked before doing the work. It has happened to me that I asked, the maintainer explained what they would want, and then I spent weeks in my free time working on a PR that never got reviewed. Just because the maintainer didn't have time. It is frustrating, but I am not entitled to anything. My PR can live in my fork.

If I need my PR to be merged upstream such that the upstream project takes ownership of it and maintains it for me, then I should look into a contractual relationship with them.

[shermantanktop]

Maintainers are sometimes not perfect. But they are providing known value, and you are trying to add something with unknown value. That's an asymmetry which doesn't look like a mutual exchange. So I'd downgrade most of the hard obligations you describe to "it's really smart to do this."

I agree with the behavioral observations. People shouldn't be assholes just because they can. That applies to everyone everywhere. Reminding someone with a bit of power to not be a petty tyrant is fine with me.

[hinkley]

I find code I wrote that violates advice I've given other people all the time. I've made release cycle mistakes on projects I maintain that I would have bet money a few years ago that you'd never catch me making.

The siren song of One More Commit or One More PR is out there, and there's always going to be some fraction of your work you do that in retrospect you should have slept on, maybe twice. (I recently fixed a problem I've been staring at for a year in an afternoon after a new, stupidly simple solution presented itself on a walk)

But there are lines, and you have to be careful not to go across them either too far or too often. Or you have to be utterly indispensable like Linus, and have a thick skin to criticism... like Linus. And if you have a thick skin to criticism you don't write long screeds about how everyone else is wrong and you're right. You just move on.

[hinkley]

> Counterpoints:

> - You are entitled to human decency. Maintainers don't get to be rude just because they run a project. This is a common thing in a lot of projects; maintainers have power, and this allows them to be rude without concern. Not ok.

There is a subtle line here and I have some sympathy for both sides of this debate because for a long time there, and in some ways is still happening under different names now, we conflated decency with respect. So it gets a little weird.

We treat the guy ringing our doorbell with decency. We treat our new boss with respect. We treat the person spouting nonsense with decency, not respect. Free Speech says I can say anything I want but it also says that you can call me names for doing so. That's the difference between decency and respect, and it's important everyone knows what they mean when they say 'decency', instead of what they think they mean.

I honestly wish there were more women participating in these sorts of conversations because they have to deal with weaponized politeness on a daily basis, and I suspect the correct line for open source is a little closer to their definition of decency than mine.

[elzbardico]

Women deal weaponized politeness a lot. There. Corrected it for you

[hinkley]

That's so edgy.

I just said that?

[chasd00]

what you're describing is how to be a nice person, that really has nothing to do with owning a source code repository. Fortunately, most people are nice but there's no requirement or obligation to be that way when setting up a public remote repository (github or otherwise).

[pessimizer]

> Maintainers don't get to be rude just because they run a project.

Everybody gets to be rude. They don't need your permission.

The rest of this is you just sort of making up standards that you're asserting that other people are obligated by "human decency" to adhere to. You're demanding ownership of other people's time and effort, and declaring that this obligation is triggered by the fact that they've already freely given of their own time and effort. You're the person who has been fed once and sues on those grounds to be fed forever.

If you, yourself, don't want to be rude, maybe reframe this as a list of suggestions that you think might be helpful to interact with people like you.