71–80 of 95 posts
Given how many improvements are ignored or rejected in so many of the open source projects, it doesn't seem like "one of the hardest parts" is hard at all. Especially when "burden of proof is on the contributor, never the repo" and the repo is hiding behind immeasurable principles such as "ultimate success of a project isn’t measured by the number of features it has, but by the coherence of its vision and whether it…
Hm, my first though is > A user proposes a new feature. It’s well-designed, useful, and has no obvious technical flaws. And yet, the answer is “no.” Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software. > This work has gotten exponentially harder in the age of LLMs. Maybe that is more of the problem. But that's probably not really "well-designed…
> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software. I think its quite easy to find examples by thinking of the extremes. - Why don't git add a native UI? (out of scope) - Why don't excel add lua scripting? (already has visual basic) - Why don't neofetch add a built-in ascii art editor so people can more easily customize their logo display? (…
Git has native UI, just a bad one just like its cli UI, so it is in scope. You've just out-of-scoped better user experience.
> - Why don't excel add lua scripting? (already has visual basic)
Visual Basic is a bad/obscure language. Even real Excel didn't stop and added some JS/Python support. So you've again just rejected better user experience, very nice "project philosophy"!
Given how many improvements are ignored or rejected in so many of the open source projects, it doesn't seem like "one of the hardest parts" is hard at all. Especially when "burden of proof is on the contributor, never the repo" and the repo is hiding behind immeasurable principles such as "ultimate success of a project isn’t measured by the number of features it has, but by the coherence of its vision and whether it…
You are free to fork and make whatever mess of features you wish for!
I don't agree; some maintainers just want the code to be /used/ somewhere and possibly in modified form, but are nto interested in upstreaming anything.
For instance the SQLite project operates like this.
> 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…
Requiring an issue per PR makes sense for significant bugs and features, but taken to the extreme it feels arbitrary and pedantic. I occasionally submit documentation fixes when I find broken docs (outdated commands in the docs, incorrect docs). I’ve had these rejected before because someone insisted I create an issue and have it go through some process first just to submit an obvious 1 line fix. At the extremes it c…
Earlier quoted context omitted.
“What if we added a GUI based web browser to CURL?”
IMHO a better example is: "Can we make a teeny tiny change to CURL that would allow me to use it as a fetch engine for the GUI web browser I'm making? I can't think of anything else that might use that change, but pretty pretty please?"
Earlier 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…
> Where it starts to get frustrating is if they throw a fit when someone forks their open source project, or when they start rejecting PRs from other people but then lightly rewriting the code and resubmitting it as their own work. Agreed, that's horrible. I would absolutely give credit at least for the idea behind even heavily rewritten code. And the freedom to fork is one of the essential freedoms of FOSS. Many peo…
Do you have any examples of this?
> 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…
Totally pointless.
> Discussion about a feature or bug is done before writing any code.
Not always. Not all PRs are significant enough to warrant discussion. For example I fixed a copy/paste bug recently where they had `foo_a = foo_b + i;` where it should have been `foo_b = foo_b + i;`. Obvious mistake. One character fix. Why on earth would I bother creating an issue and discussing how to fix it?
> There is nothing more delightful than the drive-by PR that lands, fully formed and perfectly aligned, fixing a bug or adding a small, thoughtful feature. I'm actually generally not a fan of "drive-by" PR's. Unless the drive-by PR is fixing a simple bug in a simple way, then the contributor really should've opened an issue first. Doing otherwise is rude imo. This is actually open source etiquette that I'd like to se…
You are free to say "sorry I don't want to do it like this; you've wasted your time". That's totally fine.