I personally think it's up to maintainers to set expectations. Many times maintainers will use open source projects on their resumes, advertise them on forums, give presentations, and then will be antagonistic towards even very friendly and objective issues and PRs.
Even something as simple as "I built this for my own needs and have open sourced it for open knowledge and will only fix issues that further my own needs and will not accept anything but simple PRs" goes a long way.
> Many times maintainers will use open source projects on their resumes, advertise them on forums, give presentations, and then will be antagonistic towards even very friendly and objective issues and PRs.
Is it different than someone advertising their FAANG's credentials?
Again, expecting a product to be supported unless otherwise stated is not entitlement. Expecting support is not the same as demanding or even expecting people to work for free or at all. What it does mean is that issues and PRs are treated professionally and without antagonistic behavior.
Once again, if you feel every contributor is entitled, don't open source your project or disable issues and make it very clear issues and contributions are not welcome.
For the umpteenth time in this discussion, no one said they did. And please note what I implicitly defined as supported, which is basically that a non-antagonistic conversation can be had about issues and contributions. That is not entitlement.
No. It's up to contributors to set expectations about the work they do with the project maintainer before they do it if they have any wish to see it merged.
You were given something for free. That doesnt confer any rights, legal, moral or otherwise.
Drive by pull requests are not always welcome for any number of reasons which are the sole prerogative of the project maintainers who owe you nothing.
PRs are even worse when theyre big. If you do a large PR without informing anyone you should expect by default for it to be ignored.
There are burdens on both sides and communication on both sides is important. I have had even the most simple reports receive antagonistic responses as if I was demanding (I wasn't) free work from the maintainers. That's unacceptable communication in my view. Any such communication will eliminate any willingness of mine that I had to help contribute.
> You were given something for free.
I wasn't given anything. Something was released into the open to be interacted with at some level. If a maintainer wants to complain about any interaction whatsoever, then take it private or disable issues, write a contributing (or non-contributing) guideline, and reject PRs professionally.
> That doesnt confer any rights, legal, moral or otherwise.
That's completely obvious. But like I said, a simple PR or issue filing does not imply a demand of the maintainer by the reporter or contributor. So you're basically showcasing what I'm saying isn't great, in that maintainers have this bias already set in their mind that any communication to them is a demand of their time and effort and a claim of rights, which it's very often not.
As someone who has received PRs, simply reading the PR is a demand. Hell, getting a notification about the PR is a demand.
Reading the message is a demand. Reading the code is a demand. Thinking about whether the approach is satisfactory is a demand. Thinking of a response is a demand.
If you want to maximize your chances, you had better put as much effort into making things as easy for the maintainer as possible, such as including alternate approaches you considered and why they were not chosen, written as succinctly yet clearly as possible. Your code should completely match the existing style and formatting of the code; your own style preferences are irrelevant. Of course, you need to be as polite as possible without being condescending. And even then, you are owed nothing.
That is the approach I take when writing my PRs, and my success rate is rather high (but I still get rejected or ignored).
From the maintainer's point of view, any new contribution requires work to vet it and check that it won't break something else, insidiously inject malware, etc., so what value it adds has to appear to be worth the trouble. Even when the contributor is certain that their PR is perfect and should be "no trouble" for the maintainer.
This "hill" that has to be gotten over by the contributor is just a reality of the situation. I don't see any way around it.
That's a very absolutist view. In reality, some PRs are good quality and worth paying the ongoing cost to maintain. Others are good quality, but not worth the ongoing cost.
Maintainers get to decide, and they're not obligated to publish their evaluation criteria.
Communication requires work from both side. Authors of open source software owe you nothing, including the work of communication.
At a baseline, you are responsible for the maintainer's communication burden too, such as reading in between the lines and accommodating for their schedule (they may need weeks to respond).
If you don't think it's a burden, then why not fork the project and become the maintainer yourself?
"Before you criticize someone, walk a mile in their shoes"
> Authors of open source software owe you nothing, including the work of communication.
This is a tiring discussion, because this is exactly what I'm talking about. No one is here talking about how anyone owes one anything. In fact, no one in any part of life owes one anything if you'd like to go that route. But effective communication and expectation setting avoids the vast amount of communication issues. If a maintainer wants to release software and then complain about it every step of the way and claim everyone is demanding how they spend their time and effort and not reading their mind and now bowing at their feet, that's their prerogative. But that isn't some righteous path. It's an annoying one.
If maintainers are such sensitive souls, then they should either: communicate early and stop complaining, or take the project private or disable issues and stop complaining. Why almost go out of your way just to complain and make your job harder?
>No one is here talking about how anyone owes one anything.
You were. You were describing what you "expect" from maintainers. That is the same thing as saying what you are owed.
E.g. when I make a contract I expect the other side to honor it. I am owed that because they signed a contract.
I expect people to not spit on me on the street - that's part of an unspoken societal contract.
If somebody makes a commitment, I expect them to follow through on it (even if they are not legally bound to) - again, part of an unspoken societal contract.
If I email somebody, I don't expect a response under all circumstances - again, unspoken societal contract.
What you were describing above were additional expectations you have on people who gave you something for free in exchange for nothing.
Just ask if you want to raise a PR. Explain what you want to do. Or fuck off. It's as simple as that.
You're not owed an explanation just because somebody gave you something for free. The maintainer might have complicated reasons for wanting to accept some PRs and not others and might not want to put the work in to write it down.
They're not obligated to explain this to the all and sundry just in case somebody wants to raise a drive by PR.
If you think they are obligated, that's indicative of a culture of entitlement.
Author of the pr gave stuff for free. He showed no signs of entitlement. But he is not there only one who gave stuff for free. The open source project gave code for free that is 100 times bigger than the pr. Not acknowledging that is a problem.
The author of the PR expected it to be merged. That is entitlement. They could have discussed the feature with the maintainers beforehand but AFAICT they did not.
AFAICT, the maintainer is the one lacking communication skills. Perhaps the author commented something to the effect of 'you could have told me this before I wasted my time' in the deleted comments towards the end. Or perhaps they were profanity laden. Perhaps a mix of both. We'll never know for sure.
What we do know, is the maintainer chose to ignore any communication related to this PR, for months, until someone pointed out it was helpful keeping the PR open, as it allowed people to apply it themselves locally. Then, all of a sudden, the PR is closed, and communication finally occurs. Could be coincidence, but that's doubtful considering the time span and specific comment involved.
They are obviously not the only one, developers worked on the original code and made it available under the MIT license. The author of the PR has the right to make the change and run it on their own system, they are also free to share that change to others. The project is free to reject that change for whatever reason.
The core project is given away for free, often with MIT or similar license. Thus allowing competition to build their own enterprise fork, possibly based on rejected community PRs of enterprise features.
The alternative is the code doesnt exist.
>Usually, you expect that developers
When developers give away software for free I have no expections of them. If they fix a bug I consider that a favor not an obligation on their part.
There is a culture of entitlement surrounding open source which drives "expectations" from people who give stuff away for free and it's maddening.