Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Art of Closing

blog.jessfraz.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: The Art of Closing

#11

Post by steveklabnik »

sitkack wrote: post #8

The 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…

"Submit an issue or post to the mailing list before starting a significant amount of feature work so that your work might be wasted" is a pretty common refrain in open source circles.

That said, like most tribal knowledge, it's the people who already do a lot of this kind of thing that know this kind of thing, and it's getting new people in that's the tough part.

Re: The Art of Closing

#13

Post by spdionis »

Spearchucker wrote: post #6
geerlingguy wrote: post #2

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

My thoughts everytime I hear about criticism about features of various big software products.

Re: The Art of Closing

#14

Post by hiou »

Docker is the first project I can remember using that has actually underdelivered features to the point I'm using it less and less.

I would definitely not follow their model of open source development as they are an example of the opposite and equally ineffective extreme.

Re: The Art of Closing

#15

Post by pnathan »

Down with the lowest tier of projects, I generally will always gratefully accept any help, since it doesn't come around very often. If the project is already pretty solid on tests and docs, I usually ask for them in the patch. Otherwise, I will do the grunt work there myself if need be.

Re: The Art of Closing

#16

Post by llbit_se »

hiou wrote: post #14

Docker is the first project I can remember using that has actually underdelivered features to the point I'm using it less and less. I would definitely not follow their model of open source development as they are an example of the opposite and equally ineffective extreme.

I don't think compromising their own goals and ideals is going to help in the long run. I think it is better to underdeliver and focus on quality rather than merging most suggestions that come in.

Re: The Art of Closing

#18

Post by cdetrio »

sitkack wrote: post #8

The 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…

The ZeroMQ founder, Pieter Hintjens, describes Optimistic Merging (OM) vs. Pessimistic Merging (PM) and how he supports merging sub-optimal patches just to encourage contributors: https://hintjens.gitbooks.io/social-architecture/content/cha...

Re: The Art of Closing

#19

Post by acdha »

askyourmother wrote: post #17

You would think docker would take all the help they can get, given how bad their current code base is. Maybe they should be "closing" their blog posts, and let real developers step in.

You're talking about a very popular project used in production by many people at many companies. If you're going to make a sweeping dismissal that it's terrible and all of the developers are bad, you absolutely have to back up your claims.

Re: The Art of Closing

#20

Post by kreetx »

askyourmother wrote: post #17

You would think docker would take all the help they can get, given how bad their current code base is. Maybe they should be "closing" their blog posts, and let real developers step in.

What's wrong with their codebase, care to elaborate?
Post reply on HN