No. Because unlike the one contributing a "not good enough" fix, the maintainer now has to carry the burden of continued maintenance of that fix. If that fix makes that worse, declining is absolutely reasonable. Of course that's different for fixes with just a typo-level of complexity.
Of course it is! It's up to the maintainer to decide! It's their problem, like, literally! Of course, this should not be an invitation to blindly commit and push dumb fixes, even if they solve some problem. But generally:
> If that fix makes that worse
... then it's up to the maintainer to politely ask the contributor to make the fix better, or make it better themselves, or bugger off, meaning, then ...
Imagine you ran a personal twitter account where you posted your jokes but allowed people to send theirs via email and occasionally publish them. Would you find inappropriate to tell people "yeah this joke almost kinda works but it's not funny enough for my account maybe send me a better version"?
It also puts you in that weird area, where if you take the half-finished joke and polish it, then you're stealing and/or ruining their idea. Meanwhile, if you were looking for a long-term joke-writing collaborator, then you want to encourage even the people with enthusiasm but sub-par jokes to try harder in the hope they grow into the role.
If the jokes are kept in GitHub, you can modify the joke and rebase. Include a changelog section in the amended commit. "Original" authorship is retained. When it's merged, the committer is noted in the merge commit.
But I think it's harder to determine what has changed between multiple rebases. It rewrites history, as it's said. However, I hear the reflog keeps it somehow...
GitHub keeps track of this. If you go to your commits, your own merge commits of joke-polishing would show up alongside your own.
It's heartening though that an exchange between maintainer and contributor could be like that of a maintainer and future maintainer.
The code maintainer (or owner) makes the code available to the world without asking for anything in return, but if you send him a patch he is somehow obligated to implement it? (I'm not saying this is what you're implying)
Open Source goes both ways: nobody forces you to use some rando's code off of github but also nobody forces said rando to to use some rando^2's patch for his own code
Yeah, nobody is forced to do anything, but humans are weird social creatures and feel pressure to do certain things even when not externally forced. If people were just doing a robotic cost/benefit trade off then this wouldn't really be an issue, instead both sides get a bit emotionally invested in it.
I'm not sure you can compare code commits to jokes (occasionally such is the case), but I wonder what the thought process is when a maintainer decides to do exactly that and declines a fix that fixes a problem wrong.
If the contributor is not interested in having the change merged then yes. But there might be good reasons for the contributor to have the changed maintained by the project maintainer, so many will choose to make the requested improvements (was in this position multiple times).
I mean, come on, somebody fixed it for you and when you as the maintainer complain about the quality of the fix then the FFF rule applies also!
I also have nothing against occasional little personal forks, but methinks that keeping track of the issues upon each update could be painful.