What are the little things that keep people happy and productive with the relationship?
How can open source contributors and maintainers engage in a respectful ongoing relationship?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (26)
I had been in both camps:
In user camp
In maintainer camp
Solution
I have no idea, but some thoughts:
100%
One thing I've noticed is when contributors propose a PR before discussing their approach first and you're stuck in an awkward situation where the PR would have to be modified heavily in order to be merged or you close it and turn down a new contributor. Very awkward.
The number one rule of Open Source: Always assume everything is said with the best intentions.
I think fostering engagement in open source projects is a tricky task. In my opinion, two steps are key (among others):
Being open minded about contributors ideas. If the project is truly open source, then everyone's input must have value.
Letting people know that their contributions are valuable and impactful regardless of how simple they are.
I have a different definition of open-source in my head. Open-source doesn't mean that the project should be open for all technical ideas (of course it should be open for all people to contribute and use). The idea of open-source is (my PoV):
💯
When I say being open minded, I don't mean necessarily that every idea needs to be adopted because it is an open source project. I just mean accepting different views and inputs on what could be implemented.
Picking at minor things in PRs can be a big turn-off. I feel that folks should just edit the PR to make minor changes. That feels is far more collaborative and constructive than putting in comments about typos or suggestions to rename things.
That reminds me that one of the first contributions of a feature I did the BDFL thanked me then rewrote the feature their way and pushed it out as a release. I felt that I had been listened to and I could immediately upgrade to get the feature. That was a better outcome all around than being ignored or asked to rewrite if another way.
In an ideal world, that is a great way to go about it. But most maintainers may not find the time to do all that. A short review in text is much faster, if more frustrating for the person opening the PR.
I feel it's better to make a computer do code linting, than to do this in a PR review. Nobody minds when a computer picks nits, but when people do, it's taken personally 😉
The review should focus on the logic, that the PR makes sense, and then run it though a linter for code style.
Bonus points to the reviewer for lint instructions or offer an editor.conf for the project.
But, surely it is better for you to learn the style so that your next PR doesn't need to be rewritten.
In general we are trying to build a community not just add your feature.
Probably the number one thing is keeping the communication about the ideas. (Reminder to self as well.) Avoid describing or characterizing or comparing or attributing motivations to other people. It is a lot more boring and informational, which is exactly what you want when talking about problems or disagreements. And if others make personal characterizations of you, rather than going on the defensive, ignore them and refocus back on the ideas. Examples comparing characterization vs idea.
Characterization: You are doing it wrong. You should be doing X.
Idea: Here is how I am avoiding that problem: X.
Characterization: Did you read the definition of
AbstractDecoraptorProxyFactoryPattern? It obviously says X.Idea: I think I see the problem. Try X.
Characterization: How has this bug not been fixed?
Idea: This bug is still causing a problem for me. X.
Characterization: Are you just wanting to argue?
Idea: I am still having trouble understanding your perspective. Can you give me some concrete examples?
An epic but simple thing: don't act like Lennart Poettering.
Controversial subject. Yes he's position is not what other expects, but death threats which he received is not a solution either. Since those times Linus step back from his role and Linux adapted CoC...
I disagree with the man's micro$ofty, god-module approach to systems, bereft of even a token effort at decentralization, decomposition, or enabling autonomy. And I think it likely informs or resembles his understanding of human nature.
But death threats? That's a serious and unnecessary escalation.
Welcome to the community, Matt!
I can live with any technical change as long as the core contributor says the real reason why they want something X way and ensures that I have the means to navigate whatever way that is.
I'm not an open-source maintainer or a regular contributor (would like to be, just have not gotten into it) so as an outsider, it looks like a mess of a problem to solve. You want to be open-minded and allow everyone to contribute to having the best possible product, but there seems to be so much crap to deal with. If you go to any somewhat popular repo and look at the pending issues and pending pull requests you can see this.
Open-source maintainers are putting their project out there to benefit others. Contributors want to help get involved or fix a problem they are having. It can be disheartening if the maintainer does not acknowledge any of it.
Users with good intentions could post an issue requesting something that falls outside of the vision that the maintainer had for the project. The maintainer may not want it in their project and it could spark some negative attitude in saying that.
Pull requests can just show up for features. If it wasn't discussed or asked for and the maintainer does not want it, what happens to it?
There are also the "contributors" that post issues and follow up comments that sound like they are demanding work be done without actually contributing to it. It could be in a negative or positive tone. In both cases, some person is adding stuff to your to-do list for your personal time. The negative versions are especially bad like those comments that say something along the lines of "wow it has been X months and we still don't have this." I can see how a maintainer might feel having to see that fairly regularly.
GitHub issues look like the primary form of communication but it looks like a mess to me. Anyone can create an issue with any content. It could have good content in it or it could not. It could spark a long discussion with no resolution. It could be a personal insult. There does not seem to be great built-in features on GitHub to place restrictions on these or to help gain some control over it.
If I were a maintainer, I feel like I would have some fairly strict ground rules (and make them very clear on the repo) to maintain my sanity. That likely would not go over well with a community, AKA I'd be an open-source "dictator". I would likely put restrictions on who gets to create issues (past contributors only, those who have helped others with their replies, or something along those lines), the content of those issues (needs a minimum set of information/template filled out), all PRs would be tied to an issue with an approved label, feature requests would be assigned to the user that requested it with a due date, etc. Everything else would be closed.
These are the things that usually cause contention.
Response or lack of.
Nothing more annoying than asking a question about a feature or bug and getting no answer. Especially if it's a bug that can leak sensitive data.
Dictator mode aka abuse of power.
This is more common where financial gains of some sort are expected, for example in crypto. You get to see devs that want to be the absolute authority in every and all decisions, usually to the detriment of the others.
I feel there's no margin that defines what is right for now. It's just a matter of trial and error but a lot of people get it right.
PS: source may be biased. source is me.