Hacker News Reader

Comment by makecheck | Hacker News Reader

Also, don’t send requests out of the blue. The original maintainer has to know that you’re working on something. One reason is that your changes might collide spectacularly with other planned changes you weren’t aware of. Another reason is that the maintainer might say “no” to the entire idea, much less the implementation, and save you time.

The mere creation of a fork isn’t a sufficient signal, either; the project maintainer isn’t going to treat that as a sign that you’re actually working on something. (There seem to be an insane number of forks out there that are created and never changed again, apparently used to pad résumés by having important-sounding projects listed on user profiles.)

View on HN

I think a better way to put this is "don't send requests out of the blue if you care about them getting merged".

I often hack on software that I use to make it do something I need. I then try to upstream the code, if I think that it's something others may want too. I don't particularly care about it being merged -- my attitude to this is "Here's something I found useful, if other people think it's good please take it". I'm willing to put some effort into cleaning up the patch to make it submission-worthy, but if it doesn't get merged, it doesn't get merged. I'll keep it up in a fork, and that's about it.

I don't care about it getting upstreamed enough that I will open a dialogue before I start to work on it. It's a feature I want, and I will be working on it regardless of how the dialogue goes down. The only way a dialogue can help me is by giving me implementation advice, but quite often I've already figured out a way to do it which is sufficient for my purposes (hacky or otherwise).

If there's a feature that you actually care about existing in upstream, then you should totally open an issue first and discuss it.

Why Not?

I see a problem that I can fix, I do that, and then send it back to the original maintainer, making sure that I'm not breaking tests if they exist, and providing a good description of the change. Then it's up to the maintainer to either merge it, or throw it away.

Of course, I don't have any problem with getting my PRs closed, I'm not the one who would end up maintaining the code.

> I see a problem that I can fix...

Remember, they said "out of the blue" which means "without prior contact to discuss doing so."

This exact reason was explained in the parent post: maybe the maintainers and project owners don't see it as a problem or are already working on something.

It's not just about being a machine that can crank out fixes to the individual issues in software wherever you see them. It's about participating in a social project intended to fix a larger scale problem.

> Of course, I don't have any problem with getting my PRs closed, I'm not the one who would end up maintaining the code.

A reason alone not to send PR's "out of the blue". If you're just looking to pump and dump, I'd rather not involve you in the process, only to have to do work to fix/rm code down the road.

But I mean, above all, it's your time to waste.

The post calls out major changes as deserving a chat first. My primary workflow that results in PRs is: 1) I find an interesting project, 2) I find something it doesn't do the way I want (a bug, or a config tweak), 3) I patch my fork to fix that, 4) I open up a PR incase the maintainer does think it's worth merging into upstream.

What's the upside of me opening an issue first to chat about it? The maintainer still has to burn the time to think about it, but without seeing the code that I'm proposing, which is already written because I already needed it to scratch my itch.

If they think it's worth of merging, woo, we merge it. If they want the problem fixed a different way, cool, one of us writes the PR that makes that happen. If they don't want the change, I keep using my fork.

The post in the comments was the one I was referring to. Says verbatim don't make pr's without a ping first. Says nothing of major changes.

You forget maintainers aren't computers. While your logic is correct, social norms for humans are different.

You have voices describing a human view and interest in a certain way. Whether you agree is irrelevant; the project maintainer has no obligation to listen.

It's not all about you and the workflow that makes most sense from your office chair.

> Remember, they said "out of the blue" which means "without prior contact to discuss doing so."

If I do contact the maintainer before I do any change, that means I'm making a commitment to do that change, which is not something I want to do.

> If you're just looking to pump and dump, I'd rather not involve you in the process, only to have to do work to fix/rm code down the road.

I think you should always assume with any PR, that it's a pump and dump, unless you have a history with whoever raised the PR.

> It's your time to waste.

I don't think it's a waste, it's an issue that I'm facing (or a feature that I want), so writing the code is for my own need, I'm sharing it back in case other people want it.

> If I do contact the maintainer before I do any change, that means I'm making a commitment to do that change, which is not something I want to do.

There doesn't have to be a commitment to do anything. You are opening an issue and starting a dialogue. If you then disappear, someone else can come along later and implement/fix it with the benefit of the original discussion.

Padding resumes is a bit cynical there are many good reasons to make a fork for oneself. Like ensuring you have code you depend on in the event the project is deleted

I've also seen people who don't understand how his stuff works, and fork projects before cloning them because they think that's the process. A relatively small number of clueless people could result in a lot of pointless forks.

The big button does say "fork me on github" after all.

Indeed, if you're not quite sure what to do, then that would be an obvious one to try. And it'll work in the end, so you won't necessarily change afterwards.

How are you supposed to do it otherwise ? Where else are you going to push your commits to ? Its silly to clone, fiddle with git config, make a new git repo on github/lab and then push to your new 'manual fork'. Just use the fork button.

99% of the time, when I clone an open source repository, I just want to use it, not make new commits to it.

Obviously, if you want your own copy to commit to, then use the fork button. That's what it's for. But lots of people use the fork button even when their use case is read-only.

I sometimes use the fork button just to get a copy I may or may not play with over the weekend.

How does that help? Are you just using the presence of the fork in your account as a sort of bookmark?

Yes, a complete and fully featured bookmark that won't disappear. It costs me absolutely nothing, and is ready to go when and if I need it. Why wouldn't I do that if I could ?

It makes perfect sense. This isn't what I've seen some people do, though.

Yeah, this is what I do, too. Also keep in mind, though, that you'll need to exfil your fork if you think it might disappear at all from Github. They yank the original repo and all of its forks for example if they get a DMCA notice. Years ago, I set up automation that pulls repos that I've forked, so for me, the act of forking ensures I get a copy of the code imported into my personal Gitlab instance on my home LAN.

I use stars for this, but I guess one could use forks as kind of "super stars".

Yes, I'll almost certainly star a project if I forked it. I certainly star way more than I fork, I assume most people would do the same.

Presumably you mean: "don't send requests [for new features] out of the blue"?

I would add: if you do, don't expect the maintainer to merge it. Once it's merged, it becomes their technical debt.

Nonetheless, as a maintainer I always appreciate a pull-request, and as a developer I might fork/apply non-merged patches for projects where I needed that feature as well. In some cases, since they saved me a lot of time, I might fix their abandoned/closed patch and re-submit it upstream.

Why not send requests out of the blue? This happens to me all the time and I don't mind. It means someone cares enough to try to fix their problems instead of dumping it on me.

The problem is on the other side. If you don't want the push, the sender just wasted a some work.

Not necessarily. They obviously need that change so it wasn't wasted. However they have to maintain the change themselves if it isn't merged.

How do you know they obviously need the change by making a decision away from the project management discussions?

Perhaps a solution has been discussed and is incoming from a regular developer?

They could deprecate the module where the change is "obviously" needed in a larger fix.

Frame it a different way: You're basing the needs of a project on your view of it, which, minus discussing things with project mgmt beforehand, may be incomplete.

You completely misunderstood who was needing the fix. In this case, it was the person who spent time fixing it. They likely fixed it because they need the fix.

Doesn't matter if the entire module becomes deprecated. They'll stay back with their fix (likely). Doesn't matter if another solution is inbound, they needed the fix now and not when a patch lands.

And since they already took the time to fix it - little time is lost sending a PR, regardless if it gets merged or not. If it is merged? Sweet you helped the project out (most likely). If not? Well a small bummer that you'll need to maintain your own patch(es).

This is an odd way of thinking about it. As a user of software, I like fixing it for my needs but I'd rather make the change in a way that the maintainer will accept, so that I don't have to maintain my patch. That means I'll tend to open an issue first, explain that I'm willing to submit a PR, and see if the maintainer wants to give me guidance.

I think it depends a lot on context. If I am looking to contribute for the sole purpose of improving the OSS project, then I follow your method. If I am using an OSS project in a larger commercial project and I need a bugfix or feature now, I just build it. If I think it may be useful to the OSS project, then I will contribute back with the understanding that it may not be merged.

Actually, sometimes people push changes because they intellectually think it's a better architecture or public API, but they can't survive as a fork.

They need the frequent bug fixes and upgrades from the mainline, so they really do waste their time if their changest is not approved.

Right, I love it when people do work for me. It's a bit different in larger projects, but on small side projects, it's a lot better to get people more involved rather than less so.

Given the scenario that I am using open-source software X, and that I have made changes to the software to suit my requirements, and that I believe those changes might be useful to others, I can either:

1. Contribute those changes up-stream, by sending a pull request.

2. Publicise the changes, by keeping my fork, and/or talking about it in a blog post.

3. Keep quiet, and say nothing.

4. Send an email to the original developer, suggesting I may have some useful changes, and asking whether I should send a PR.

If I start working on changes without notifying the original maintainer, well, I might do work that's useless, that maintains no value, that isn't sustainable. But that's my loss.

If I send a PR, the net loss is the maintainer's time to review my PR (if they choose to).

Many open-source contributions stem from sending PRs out of the blue. You're right to say that it can be an inefficient mechanism in some circumstances; it's just that a lot of developers are OK with that.

If you've already made the changes, then by all means, just send a PR. The worst thing that can happen is that it won't get merged.

If you're considering doing some work, please talk to the maintainer first. Otherwise it might lead to unhappiness all around, because, as a maintainer, I don't like turning down all this work you've done for free any more than you do, but there's not much choice when it's a net negative (for any of the reasons in the article).

Exactly. Too often I get a large PR that I call a 'code dump'. at least give a couple paragraphs of explanation behind the changes. Sometimes a conversation can start in a PR, but it's more rare that results in merged code than if there was an issue first.

Yeah, I semi-recently had to fork a library, make some big changes to get it working for us, then made an issue with the main repo basically saying "Hey I needed this and don't have time to do it properly, Here is what I did, and I ham-fistedly ripped out everything i'm not using. Look at these few files for an example of the core change that's needed. I'm willing to help work on a real solution later, but I can't right now"

The maintainer saw what I did, and was able to easily make the change so it conformed to their style, their architecture, and they worked with me later so I could make the doc changes.

I felt like that worked magnitudes better than when someone makes a big PR with a potentially controversial change and lets the maintainer decide what to do with it.

  as a maintainer, I don't like turning down all this work you've done for free

I empathise with that perspective, and I appreciate any work that an open-source maintainer does to contribute to a project, so thank you.

I must confess, I often submit patches without prior warning or discussion. They almost always come out of client work: I've been asked to deliver a requirement, so I do what I have to do to deliver that.

When I have to modify upstream code, I know that my use-case might not be appropriate for everyone (so I try to explain that in my comments). But even if I think it's a patch that isn't going to be accepted, I generally post it anyway: partly for the few people who might share my use-case, but also for me, in my next project, where I may run into the same problem again.

Sometimes my PRs are nothing more than a note-to-self. A lot of the time that's been dictated by client policy: projects where I could only modify third-party code if there was a published upstream patch for the changes. So if I have to modify upstream code, I have to record a patch/PR upstream, to comply with client policy. But I do understand that the answer to the PR may well be "no".

That's pretty much the best scenario, I think. If you won't be offended by the fact that I may not consider the PR appropriate for the codebase, I appreciate the time you took to post it for consideration (and thank you!).

what on earth are you talking about? I pull a project into my codebase, find it has bugs or missing features so i fork it, make my changes and PR.

If I fork, write the code and follow the outlined contribution guidelines (which often do not include "ask for permission") then I'm doing what I should in the OSS world.

I work on many things for software projects for my own personal gain. I don't particularly care if someone is planning to do something similar in the future. I need this thing now, for whatever project I'm currently doing.

I implement it, and sometimes I may send a PR to see if the maintainer wants it. I don't particularly care if it gets accepted or not. However I think giving them the option to pull if they want it, is a good idea.

At the same time, sometimes, the best argument for a big new idea is _code_ showing that it works in reality. Obviously, if you're going to do a major refactor on your own, you're risking that work being thrown away. So, it's certainly a risk.

Reply on news.ycombinator.com