> That's super gross, and that's the reason I so rarely contribute nowadays to medium to big FOSS projects.
Reading that PR discussion, I don't see any sort of 'gross'-ness.
The submitter submits a (presumably unrequested) PR. One project maintainer adds comments to bring it up to project standards. Later, another dev clarifies that after discussion, they agree that it doesn't belong in the core project.
For anyone else out there who doesn't like 'their time wasted', discuss your idea with project maintainers before submitting a PR. Just because you think it is a good idea doesn't mean it fits within their vision for the project.
For FOSS at least, ultimately maintainers and authors are not beholden to anyone who wants to submit code, it's perfectly ok to say NO even for political or emotional reasons... so if not in the direct context of a PR then where?
I think heated and unconstructive PRs probably arise as a result of pushy and entitled submitters, after a certain point authors will inevitably get fed up and abandon diplomatic approaches.
>Shocker: when I reviewed the code for both projects, I sent fixes to the one that I found to be of high quality. Why is this surprising?
Pointing it out doesn't mean it was "surprising". Just that it happened -- and as such, it could be a possible conflict of interest.
"Contributor to project X trashes competitive project Y" is a different situation than "Totally unaffiliated with X and Y person, trashes Y".
Perhaps there was bad blood between the two projects, a backstory with interacting with them, etc -- in which case it would be good to know, that's why I asked.
Now, if there were more technical arguments it wouldn't matter -- they could be evaluated regardless of who tells them --, but your comment was mostly summed to: "they are inferior quality" and "they only succeeded because they use vim's name directly", which doesn't leave much to evaluate.
> I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!".
Then you shouldn't contribute to someone else's project.
It very often happens in FOSS that a contribution is well-intentioned, but doesn't match all qualities of the project, and asking them to fix it vs. rewriting wastes a lot of time. I've seen this pattern several times before: First-time contributor delivers patch, reviewer thinks "The idea is great, but it's faster if I just rewrite it rather than give feedback."
Consequence is, first-time contributor will not contribute to this project again.
FOSS maintainers can learn some pedagogy here.
I tried having a patch rejected only to see the maintainer rewrite my patch that introduced bugs.
> It's unfortunate that some loud and rude people have put you off of contributing to free software.
I've been told this directly by project maintainers when filing bug reports (usually along the lines of "PRs welcome"), so it's not just that seeing this stuff on the internet puts me off from contributing in general. It's that people tend to respond directly with it whenever I come near their project.
Do they? The projects I maintain I do so for myself and work.
> By alerting the maintainer to issues, I would be helping them
Do you? I need to weight the time and effort to understand your issue against my potential gain from it.
> The nuclear option for a maintainer is to completely ignore the user base whose attention they need
Odd, I don't need attention for my projects.
> as if owing was any part of any of it
You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor".
> But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports
If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)
I don't know about that. I maintain a small project and I've received exactly one outside contribution, and I made sure to properly credit that. Nobody is going to send me patches in order to gain social standing. But popular open source projects are a different matter and the maintainers there are hip to the fact that people use often minor contributions to increase their standing. Now: the OP clearly went beyond that, and I'm on the same side as another commenter here in that the 'Suggested-by' tag would have been the more appropriate one. But that's hairsplitting to me and if that's worth penning a post like this for, especially one that misrepresents the kernel maintainers words in a meaningful way then all perspective is lost.
> all an open source maintainer owes you is a P.R. review.
What? Given what you said in your first sentence, this seems a bit contradictory. When I post some code online, nothing forces me to review PRs other than an implicit social contract.
The likelihood of a rational person ignoring PRs/issues seems pretty low, since one typically wants improve their software. Nonetheless, it definitely happens for one reason or another and it's not something worth complaining about unless you're given some sort of a priori quality assurance.
I'm sure there are thousands of projects on Github which have a 0% response rate for PRs/issues. This isn't bad -- it just is. It's entirely someone's right to post a project and forget about it, regardless of how popular it got later on. Radio-silent projects will almost never get popular, since there's an implicit meta contract around support, feedback, etc.
> many open-source projects' Codes of Ethics/Conduct/whatever make me feel explicitly unwelcome
Most open source projects Code of Conduct boil down to "don't be mean to other contributors, treat them well". I'm sorry this makes you feel explicitly unwelcome. That said, it's never been a problem for me to adhere to that.
This is a first time for me being excluded, and it feels bad. I'm commenting on why this person has gone out of his way to do that.
Exclusion is not the norm in online programming spaces. Nor would we tolerate it if someone started excluding people on the basis of something like race. But seemingly there are apologists for exclusion on the basis of religion.
> Well, "shunned" might be a bit too strong, but I don't speak native English.
In native english the tone of the following sentence is considered "not very nice":
> but seems weird to put the responsibility about you not forgetting something
Further...
> it's just a helpful note regarding how to respond to feedback.
And what you responded with is NOT how to respond to feedback to an open source maintainer.
> Let's cool it down with trying to start up some heated argument around this, no one is interested in that.
Nor am I. I'm sorry you feel like you're getting picked on here. This general topic is a huge issue for the future of FOSS contributors. What you responded with is clearly not egregious (e.g. i've seen people say things like "hey I submitted a ticket on GitHub 3 months ago and no response, WTF!?!?"...that is VERY BAD), but every little bit hurts. Don't take offense to it, especially if english is not your native tongue.
> But other than that, all you'll get is a load of entitled users complaining about bugs, usually filling low quality bug reports, and very few actual meaningful contributions.
I agree that entitled users can be a real problem. I have had my share of dealing with entitled and impolite users complaining about "issues" that eventually turn out to be something that is already easily addressed by the README. Interacting with such users can indeed be disappointing.
However, except for the occasional discourteous user, most users of my tiny projects have been quite supportive. Most of them are polite while submitting bug reports. Some even leave comments to express their appreciation for the project![1] So it's not all bad!
> Most people are just like you and want THEIR PROJECT to be popular, not to contribute almost anonymously to some other random guy's popular project.
Wanting one's own project to be popular and contributing to other projects need not be mutually exclusive. Many people write their own projects as well as contribute to other projects. For example, I got into open source first by contributing[2][3] to other projects before I began publishing my own projects.
> Being an open source maintainer doesn't mean you're entitled to recognition or praise or deference. You're not entitled to put out low-quality software and have others pretend it's awesome. You're not entitled to make claims that are false and not be called out for it. You're not even entitled to people not trashing your work.
That's fine and all but you are entitled to control your own repo, its issues, pull requests, and related fora. You are entitled to set the acceptable standard of communications and if you don't like the way someone is communicating you are entitled to shutting that off.
See, entitlement works both ways: as a maintainer you're not entitled to a lot of things, but as users others are also not entitled to lots of things.
Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features. Users have to weigh up their own time and priorities too, so for users to give up their free time to put work into documenting issues / feature needs, that is a bunch of free labor given to the project maintainer. Any maintainer who sees bug reports or feature requests as a time drain instead of free product research is completely wrong.
> Odd, I don't need attention for my projects.
Then why are they open source?
> You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor".
No, I never said anything like that, in fact I said the opposite. Maintainers are perfectly free to ignore users if they want. It would just mean it’s reasonable for users to see that as a shitty owner and express frustration about it. Maintainers don’t owe anyone anything, and I never said otherwise. But it’s perfectly legitimate for users to express frustration over badly managed FOSS projects, neglected feature requests, etc.
In other words, “if you don’t like it, leave” is unjustified, and users should express frustration. It doesn’t mean a maintainer is going to listen, but that’s beside the point. The original comment I replied to proposed that users are ingrates or should possibly be banned if they “complain” - that if they have a problem, it’s not the maintainer’s problem.
These are just wrong attitudes. Maintainers aren’t obliged to do anything. Irrelevant. Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.”
> If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)
No, this is up to the users to decide, as they actually use the project. Users decide if filing a bug report, asking for a feature, or pushing back on a roadmap is needed, because it stems from the problems they experience as users. Of course the maintainer doesn’t have to care or even read it, but that would be horrendously undiplomatic of the maintainer, and users would have every justification to express frustration about it.
> It's unacceptable for you to demand that open source developers spend their time addressing your concerns for free. Period.
Do you understand the difference between that and general criticism of a project?
If you had to write guidelines on criticizing a project like Gnome in an acceptable way, what would they be?
My suspicion is that you think any criticism is unacceptable, but if you have some actual guidelines other than "people are mean to Gnome" I would be interested in hearing them.
Personally I think you've been very disrespectful during this thread, but as I generally enjoy debate I've been willing to put up with it until now.
I don't know the details of this, but I think the first response in the thread makes sense and reflects what I thought straight away:
"I'm sorry to hear about this unacceptable prejudice, as you've described it.
My question is: should this be taken as an indictment of the entire GNU
project, or those individuals managing personnel at the FSF's offices? I would
hate for the intolerance of one or a few people to be construed as a reason
for the entire GNU project not to exist"
"I think he behaved poorly in relation to two topics I care
about: leading open source projects, and ending sexism."
I would think that the best way to do that is to lead by example by leading and open source project and combatting sexism in the project(s) you lead instead of knocking down my strawmen.
If you lead an open source project and fight to end sexism, then great. If not, you are in no position to criticize Ben.
"I also think people [who have contributed to] the project have
a right to criticize him. [Everyone else can GTFO]. He does owe
them an explanation; any action taken in the project's name is
subject to review by the project community."
FTFY. This entire ordeal would have been a non-issue if you could mute non-contributors.
My true agenda? Establishing a culture where non-contributors don't waste the time of contributors with their bikeshedding.
What excludes someone from the category of non-contributor? They submit test cases. They clarify documentation to make it clearer how to use the code or understand the algorithms in the code. They implement features. They participate in design discussions. They contribute use cases and elaborate on why those use cases are important. They fix bugs in the open source code instead of simply hacking around it in their own code. They write blog posts on how to use the open source code. They publish examples of the open source code in use. They give talks on how to use the open-source code.
> Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence.
I think in a perfect world every request would be polite and reasonable, making what you say here objectively correct. Since this is not the case, this sadly becomes a subjective opinion.
The fact of the matter is that when one deals with the general public in any form you get all forms of good and bad interactions.
There's also an inherent asymmetry between the effort it takes for a small number of project maintainers to respond to a large number of project consumers.
There's no clear-cut answer here, but I think it is reasonable to state that someone sending requests to a project should set their expectations to match whatever licensing or contractual agreements are present in the projects they interact with.
a key person from FSF commented on the project. he didnt say it is not notable
on the other hand this is a rewrite of GNU coreutils, and as such FSF has every right to comment in the project
reply