Why I close pull requests
jeffgeerling.com
Why I close pull requests
1–10 of 188 posts
Re: Why I close pull requests
#2Also, 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.)
Re: Why I close pull requests
#3Just stopping by to point out that there is a typo in the first sentence of the article, I think: in "I maintain over many", the "over" should not be there.
Now I will read the article. :)
Re: Why I close pull requests
#4Just stopping by to point out that there is a typo in the first sentence of the article, I think: in "I maintain over many", the "over" should not be there. Now I will read the article. :)
Also "the bus factor is high". Should be "low", as it is 1 for most projects.
Re: Why I close pull requests
#5Also, 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…
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
Re: Why I close pull requests
#6Also, 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…
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.
Re: Why I close pull requests
#7Also, 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…
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.
Re: Why I close pull requests
#8Also, 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…
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.
Re: Why I close pull requests
#9Also, 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…
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.
Re: Why I close pull requests
#10Wow, managing over 160 projects? I can imagine that he has to close quickly.
At GitLab we have a written down definition of done so people know what should be in their merge request, see https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...
And our merge request coaches try to get people over the finish line instead of closing. But that are full time people on a single project. Maintaining 160 projects is a whole different ballgame.