Earlier quoted context omitted.
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.
Why I close pull requests
41–50 of 188 posts
Re: Why I close pull requests
#42Wow, 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…
I try to at least indicate if it's close to ready for merge or if it will need a bit more work, and don't often immediately close a PR.
Re: Why I close pull requests
#43Earlier quoted context omitted.
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…
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…
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".
Re: Why I close pull requests
#44Earlier quoted context omitted.
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.
Re: Why I close pull requests
#45Earlier quoted context omitted.
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 p…
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.
Re: Why I close pull requests
#46Earlier quoted context omitted.
> 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 p…
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 ha…
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.
Re: Why I close pull requests
#47At Google, if you want to implement new features (or large refactoring), you'll need to write a design doc. In which, you should answer questions your reviewers might ask (common questions like: why do you want to do this, what are the alternatives, how components interactive with each other before/after your change). This is something like Python's PEP: you need a proposal to convince your reviewer that you have put…
Google's design document culture is bad. Google has succeeded in spite of it.
In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become increasingly out-of-date as the code evolves, creating anti-documentation that makes it take longer to understand code. Yes, yes, people should update design documents as the code evolves. Everyone knows that in practice, nobody updates old design documents.
Design documents make it too easy for other developers to shoot down ideas. Sometimes the worth of code isn't apparent until it's made. It's far too easy for someone to comment "this will never work" on a proposed change. It's much harder for someone to deny benchmarks attached to a proposed change. It's too easy for reviewers to knock out functionality.
Design documents turn every feature into a half-assed, lowest-common-denominator risk-minimized barely-adequate shell of itself.
The real reason everyone at Google writes design documents is that promotion committees demand documents as "evidence of complexity". No design document, no impact. No impact, no promotion.
Code is just code. Bad changes can be backed out. It's much better to move fast and iterate quickly than to create an illusion of care and add friction to every aspect of the development process. Up-front design of software just does not work. If it did, waterfall project planning would be successful.
These questions you highlight --- Why are you making this change? What impact will it have? --- can be asked during review of actual code. There is no need to build a speedbump, not if you trust your people.
Developers should be able to choose to create design documents and solicit feedback. Most changes don't need this process. You should trust developers to know what changes require a more extensive discussion and which ones don't.
A culture that requires permissions and signoffs before work can begin is a culture that leaves products stagnant for years.
Re: Why I close pull requests
#48Re: Why I close pull requests
#49I also maintain a great number of projects (perhaps more) and generally I give feedback on why a PR is unacceptable and leave it open until it's resolved. Sometimes I'll close it a year or two later.
Re: Why I close pull requests
#50At Google, if you want to implement new features (or large refactoring), you'll need to write a design doc. In which, you should answer questions your reviewers might ask (common questions like: why do you want to do this, what are the alternatives, how components interactive with each other before/after your change). This is something like Python's PEP: you need a proposal to convince your reviewer that you have put…
Requiring permission to do work is the enemy of progress and engineering dignity. It creates a presumption of incompetence and an atmosphere of low trust that punishes people who want to push the envelope of what's possible. Google's design document culture is bad. Google has succeeded in spite of it. In my experience, having worked at many large tech companies, design documents obfuscate, not enlighten. They become…
>Design documents turn every feature into a half-assed, lowest-common-denominator risk-minimized shell of itself.
Sounds like a sentence written by someone who is an engineer and not a support staff or a user, i.e the people who have to deal with the fallout of every feature change and every engineering decision. I could just as easily substitute "feature driven design" into most of your points above.
Requiring someone to put thought into the design of a product and to subject that thought to rigorous scrutiny is, on the whole, a good thing. One that leads to products end users want to use.