What would be an example of a well-designed, useful feature that doesn’t mesh with the philosophy of the project?
“What if we added a GUI based web browser to CURL?”
An open-source maintainer's guide to saying “no”
31–40 of 95 posts
Re: An open-source maintainer's guide to saying “no”
#32> ... articulate the project’s philosophy, setting expectations before a single line of code is written... Historically, we could assume that since writing code is an expensive, high-effort activity, contributors would engage in discussion before doing the work, or at least seek some sign that time would not be wasted. Today, LLMs have inverted this. Code is now cheap. No. We could n ot assume that contributors would…
> No. We could not assume that contributors would engage in such discussion, in the past; nor has this been inverted today. If the author experience a shift in the nature of PR and discussions, then at the very least it's been inverted in the projects they maintain. Even if there were contributors that did so in the past, if the ratio increased it's an issue worth discussing. > Code "discusses itself" with you as wri…
> ... is not a great push request.
indeed, but that is no different now that it was before.
> If you have to think it through in front of an IDE to think about it properly, script it out in some quick python
Again, that is not possible; or rather, it is meaningless. It's like telling an author to sketch out a few chapters ahead. It doesn't work like that: The story has its own life and nature - even if, to an extent, drawn out from the author's psyche and unconscious - which develops through the process of writing. The sketches are very often just not what the story works itself out to be. In fact, not unlike literature - sometimes, truths reveal themselves only on the first or second rewrite.
Re: An open-source maintainer's guide to saying “no”
#33Earlier quoted context omitted.
> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software In my experience, there is a subset of open source projects where contributions are theoretically accepted, but in practice the maintainer doesn’t actually want to accept anything from anyone else unless it’s something they’ve asked for. They view contributors as assistants who are willing t…
I had a somewhat similar experience with libjpeg-turbo. Found a real bug, submitted a working PR, needed to argue my case that the bug was real despite providing examples, and eventually the maintainer paraphrased my PR into their own PR and landed their own fix. It's fine I suppose, but it was a weird experience.
sometimes people have a strong vision for the code they maintain. in those cases they'll usually more happily accept issues, rather than code. but GitHub doesn't let you turn off prs...
Re: An open-source maintainer's guide to saying “no”
#34> we recently tried to nudge this behavior by requiring an issue for every PR I've not maintained or worked much with open source. But i would have assumed this was already common? It reflects how (from my experience) companies work internally with code. Discussion about a feature or a bug is done before writing any code (over lunch, or in a issue thread). We don't want to pay someone to write a feature we don't agre…
I made a lot of PR for Chez Scheme (and indirectly Racket). For me it's easier to write the code, perhaps because I'm not an English native speaker, but my Spanish is bad too.
Most of my PR are like 30-50 LOC (including comments and tests), with a few very related features, and I have probably a 90-95% merge rate. Sometimes writing the explanation takes a long time. Many times while writing the code I get a lot of small surprises and unexpected corner cases. So most of the time a previous discussion would be too generic to be useful for me and inteligible for the maintainers.
Anyway, my idea is to take only a few hours (4?), perhaps distributed in a few slow days. So if it's not merged it's not a big deal, not hard feelings. Also a short feature is easier to review and modify if necessary.
Re: An open-source maintainer's guide to saying “no”
#35Maintainers really do need to say no more often, and teach users to be way less entitled. helping maintain a big project you see all sorts of users trying to push features just for themselves onto you.
Re: An open-source maintainer's guide to saying “no”
#36What would be an example of a well-designed, useful feature that doesn’t mesh with the philosophy of the project?
"What if we allowed posting GIFs to hacker news posts and comments?"
Re: An open-source maintainer's guide to saying “no”
#37My pet peeve is people who use LLMs to generate code, never check whether it works, and then submit a PR.
As if open-source maintainers don't have enough chores.
Re: An open-source maintainer's guide to saying “no”
#38Maintainers owe users absolutely nothing.
This is how open source was back in the day:
- Someone puts code out there
- You fork, then use code. Maybe you change it, put it out there
- Someone forks it back if they like the changes
That's it. No one owes anyone a single thing except following the terms of the license.
Want a change? Do it your self, pay up, or fuck off and wait for someone else to maybe do it, or not do it at all, depending on how they feel.
Re: An open-source maintainer's guide to saying “no”
#39Earlier quoted context omitted.
I had a somewhat similar experience with libjpeg-turbo. Found a real bug, submitted a working PR, needed to argue my case that the bug was real despite providing examples, and eventually the maintainer paraphrased my PR into their own PR and landed their own fix. It's fine I suppose, but it was a weird experience.
sometimes people have a strong vision for the code they maintain. in those cases they'll usually more happily accept issues, rather than code. but GitHub doesn't let you turn off prs...
It's hard to know without looking at the datails, but in this case it would have been nice to add in the commit
> Thanks to @whoever for reporting the bug and providing a fix prototype.
(Probably prototype is not the correct word, but something like that.)
Re: An open-source maintainer's guide to saying “no”
#40My pet peeve is people who use LLMs to generate code, never check whether it works, and then submit a PR. As if open-source maintainers don't have enough chores.
Over the last 6 months this has been my experience with new engineers at work, absolutely awful. I wish people didn't feel the need to throw out SDLC once the LLMs came along.