7 ms·

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

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.)

Skuzzzy 10y ago
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
- mikeash 10y ago
  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.
  - tedunangst 10y ago
    The big button does say "fork me on github" after all.
    - mikeash 10y ago
      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.
  - ageofwant 10y ago
    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.
    - mikeash 10y ago
      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.
      - ageofwant 10y ago
        I sometimes use the fork button just to get a copy I may or may not play with over the weekend.
        mikeash 10y ago
        How does that help? Are you just using the presence of the fork in your account as a sort of bookmark?
        ageofwant 10y ago
        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 ?
        mikeash 10y ago
        It makes perfect sense. This isn't what I've seen some people do, though.
        fapjacks 10y ago
        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.
joejev 10y ago
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.
- marcosdumay 10y ago
  The problem is on the other side. If you don't want the push, the sender just wasted a some work.
  - rpedela 10y ago
    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.
    - asdkjfsad888 10y ago
      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.
      - Nadya 10y ago
        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).
meesterdude 10y ago
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.
mgbmtl 10y ago
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.
alaaibrahim 10y ago
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.
- asdkjfsad888 10y ago
  > 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.
  - akerl_ 10y ago
    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.
    - bcuzitsppl8383 10y ago
manarth 10y ago
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.
- StavrosK 10y ago
  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).
  - geerlingguy 10y ago
    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.
    - Klathmon 10y ago
      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.
Manishearth 10y ago
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.
UK-AL 10y ago
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.
acjohnson55 10y ago
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.

Skuzzzy 10y ago

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

mikeash 10y ago
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.
- tedunangst 10y ago
  The big button does say "fork me on github" after all.
  - mikeash 10y ago
    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.
- ageofwant 10y ago
  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.
  - mikeash 10y ago
    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.
    - ageofwant 10y ago
      I sometimes use the fork button just to get a copy I may or may not play with over the weekend.
      - mikeash 10y ago
        How does that help? Are you just using the presence of the fork in your account as a sort of bookmark?
        ageofwant 10y ago
        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 ?
        mikeash 10y ago
        It makes perfect sense. This isn't what I've seen some people do, though.
        fapjacks 10y ago
        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.

joejev 10y ago

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.

marcosdumay 10y ago
The problem is on the other side. If you don't want the push, the sender just wasted a some work.
- rpedela 10y ago
  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.
  - asdkjfsad888 10y ago
    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.
    - Nadya 10y ago
      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).

meesterdude 10y ago

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.

mgbmtl 10y ago

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.

alaaibrahim 10y ago

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.

asdkjfsad888 10y ago
> 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.
- akerl_ 10y ago
  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.
  - bcuzitsppl8383 10y ago

manarth 10y ago

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.

StavrosK 10y ago
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).
- geerlingguy 10y ago
  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.
  - Klathmon 10y ago
    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.

Manishearth 10y ago

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.

UK-AL 10y ago

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.

acjohnson55 10y ago

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.