Not every contribution you make to free software is going to be accepted, deal with it!
We are not perfect and project maintainers have always the last word.
It's frustrating, it totally is, but we have to be humble and understand.
If you don't like it -> fork the repo.
But that makes you the maintainer of the fork and that's too much work to do amirite?
@ekaitz_zarraga well, I understand this, but this doesn't mean the maintainers don't need to communicate their reasons for accepting / denying changes.
Maintaining is not only a technical responsibility, but a social one as well. That's why maintainers should be respected.
@alxd well cached subtoot. :)
I didn't want to answer you in your thread because I didn't want to sound as criticizing you or something. I know how it feels and I didn't want to put more gas in the fire.
Maintainers have a social responsibility?
Yes IMO. But maybe not in theirs. It depends on what the maintainer makes the software for.
I made some patches to software before github was popular and many of them were aggressively criticized and rejected and that's not necessarily bad.
@ekaitz_zarraga I am still learning and I welcome all the criticism to the patches / changes I propose. I can wait for review and feedback and I'm okay with that! I really appreciate the time dedicated to my changes.
What I don't like though:
- bad communication
- unclear requirements
I'm not maintaining any package not because I'm afraid I wouldn't have the expertise to do it, but because I might not have enough time / attention to communicate clearly and on time.
@alxd Me neither mate, but most of the time we can't ask maintainers for anything because they maintain software for free.
We have to remember the amount of issues and PRs that, for instance, Mastodon has.
One person is not enough for handling all of them with attention. It's just impossible.
So, we have to understand and try to not take things personally, because they are not personal.
@alxd Also, further than your specific case, what I see here in mastodon is that many not-software-related people is trying to make mastodon work as they think is good, but they don't really understand how software worked for years.
That's a problem because then frustration comes, and strange forks that never go anywhere appear.
They appear because people sometimes don't understand the huge job Eugen is doing.
He takes bad decisions sometimes. He's a human. But the job is huge.
I see this as a problem: Mastodon should have designers. Features should be discussed in public issues. Singular decisions without community input - whether mine, Gargron or whoevers - are damaging in the long term.
> Does that mean that one maintainer can waste free work of contributors?
If you consider any work that doesn't get accepted by an upstream maintainer a waste AND if you consider the maintainer responsible for such waste.
I don't think so, though.
#Free code is never a waste.
Keep it free, reachable somewhere, and somebody might pick it later.
Or #fork the project.
I've spoken with many hackers over the years and I see this as really painfully technosolutionist approach.
Can't you see the _social_ price of a fork? Yeah, awesome, I can copy the code, but then I need to go around convincing all the pod maintainers to use my fork instead of the default one.
The "defaultness" is a huge force. That's why Windows is so popular.
If you're not contributing your changes upstream you shouldn't expect others to run it. (Though they might) And many people might be fine with that.
The only issue comes if you break compatibility, but that's why we have standards.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!