The Art of Closing
blog.jessfraz.com
The Art of Closing
1–10 of 26 posts
Re: The Art of Closing
#2As a maintainer of dozens of fairly small OSS projects on GitHub, I learned early the importance of 'No'. Also, unmentioned here, you have to be willing to ignore the 'me too' present in a lot of PRs and feature requests; what's most important to me is 'will this new code/feature make the project easier or harder to maintain?'
If harder, it had better be a stunning new addition that makes the extra maintenance worth it... And often, it had better include an automated test!
Re: The Art of Closing
#3An anecdote [1] about "No is temporary, Yes is forever":
4 months ago: However, please read the notes in Roadmap and new features before continuing with this work, as I'm not yet sure whether or not they are within the scope of Umbrella
[...]
4 months ago: I don't think it's a good idea to change it, so only Strings will be available for after, before, etc.
3 months ago: I opened it to implement what was suggested here.
3 months ago: Okay, it was added.
Re: The Art of Closing
#4As a maintainer of dozens of fairly small OSS projects on GitHub, I learned early the importance of 'No'. Also, unmentioned here, you have to be willing to ignore the 'me too' present in a lot of PRs and feature requests; what's most important to me is 'will this new code/feature make the project easier or harder to maintain?' If harder, it had better be a stunning new addition that makes the extra maintenance worth…
Oh yeah, and even in regular work too. I've noticed a lot of peer pressure in many different environments, sometimes team members feel obligated to provide a "me too" or "thumbs up" or whatever, out of fear of being the nail that sticks up and gets hammered back down.
Re: The Art of Closing
#5As a maintainer of dozens of fairly small OSS projects on GitHub, I learned early the importance of 'No'. Also, unmentioned here, you have to be willing to ignore the 'me too' present in a lot of PRs and feature requests; what's most important to me is 'will this new code/feature make the project easier or harder to maintain?' If harder, it had better be a stunning new addition that makes the extra maintenance worth…
Asking the author of a PR to include an automated test is a favor to the larger community - you're building momentum for this practice. As a maintainer, you shouldn't feel bad about introducing this sort of hurdle. (And if you don't have the infrastructure to run those automated tests, then it's a good excuse to get it up and running!)
Re: The Art of Closing
#6As a maintainer of dozens of fairly small OSS projects on GitHub, I learned early the importance of 'No'. Also, unmentioned here, you have to be willing to ignore the 'me too' present in a lot of PRs and feature requests; what's most important to me is 'will this new code/feature make the project easier or harder to maintain?' If harder, it had better be a stunning new addition that makes the extra maintenance worth…
I imagine a similar rationale is used by big vendors to select features for products like Windows, Android, Safari, Outlook... The business proposition is sound, but to the user "Microsoft just never learns", or "Apple need to start bringing their hardware quality to their software", and so on.
Re: The Art of Closing
#7I have a policy to accept anything what is not a total crap. It is easier to edit and fix code, than educate random people. And I might remove that patch before stable release anyway.
Granting commit access is different level.
Re: The Art of Closing
#8The pain of having a patch rejected is because of the asymmetry. No is _easy_, the submitter often put hours of work into understanding the codebase, the architecture the style of the code, figure out how to fix a bug or add a feature and then to have the response be, "No", feels like a pretty harsh rejection.
How we structure work on these projects needs to be rethought so that the majority of these don't happen. The attitude of code-or-gtfo is kinda broken with respect to how much work people put into a project with an uncertain outcome.
Maybe we should
* submit an issue outlining new feature, or technique to fix bug
* create a branch, reference that issue
* update issue for a branch review, get greenlight
* do possibly hours worth of work
* submit PR that isn't outright rejected
Re: The Art of Closing
#9The pain of having a patch rejected is because of the asymmetry. No is _easy_, the submitter often put hours of work into understanding the codebase, the architecture the style of the code, figure out how to fix a bug or add a feature and then to have the response be, "No", feels like a pretty harsh rejection. How we structure work on these projects needs to be rethought so that the majority of these don't happen. Th…
> No is _easy_, the submitter often put hours of work into understanding the codebase [...]
And maintainers will put many, many more hours into maintaining it. The submitter only has to interact with us once. We have to interact with their code for a long time.
> How we structure work on these projects needs to be rethought [...]
Most projects work the way you described (including Docker). You open an issue (and/or send a mail to the mailing list) describing the problem and a proposal to fix it. We then discuss the design and once the maintainers all agree with the design (more or less) you move onto creating a PR.
Sometimes maintainers won't agree, and it'll take writing a PR to convince them that it will work (this does happen). But in most cases, the design is the important part (if it's a non-trivial change).
The only counter-example I can think of is the Linux kernel. But that's an extreme example and usually a dummy PR will be enough to convince them to discuss your idea.
Re: The Art of Closing
#10From the opposite point of view, before writing a significant patch/feature, it may be worth opening an issue with a quick description of what you'd like to implement to see if there's interest in it from the maintainers before investing the time in writing it. It may even be something someone is already working on in a private branch.
Even if it's something you really need and plan on maintaining your own fork if rejected, you could still get some tips on how to best implement it or potential tricky bits to be aware of.