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

The Minimally-Nice Open Source Software Maintainer

brson.github.io

Post reply on HN
Print view View original

21–30 of 61 posts

Re: The Minimally-Nice Open Source Software Maintainer

#21

Post by no_protocol »

jochakovsky wrote: post #16
no_protocol wrote: post #9

One thing I wish GitHub made easier is responding to a pull request with a patch rather than encouraging reviewers to type up a bunch of suggestions that the original submitter will have to turn into a patch themselves. If you have a better idea how to accomplish part of a suggested change, you can communicate that more clearly by making a patch and leaving a comment explaining why. GitHub should encourage this and a…

Could this be accomplished with a pull request into their feature branch?

Absolutely, and I've done that before, but the web interface doesn't really help with this. You also need to alert the original thread about it manually so others can follow the thread.

If you have five different suggestions, should that be five separate PRs to their feature branch? Probably? Or they will just need to modify or rebase out the commits they don't want.

Anyway, I just like all solutions where "doing the work" is encouraged over "talking about doing the work." Often, the doing takes less time for both sides.

Re: The Minimally-Nice Open Source Software Maintainer

#22

Post by no_protocol »

steveklabnik wrote: post #19
no_protocol wrote: post #9

One thing I wish GitHub made easier is responding to a pull request with a patch rather than encouraging reviewers to type up a bunch of suggestions that the original submitter will have to turn into a patch themselves. If you have a better idea how to accomplish part of a suggested change, you can communicate that more clearly by making a patch and leaving a comment explaining why. GitHub should encourage this and a…

Have you seen https://github.com/blog/2247-improving-collaboration-with-fo... ?

Yes, that is very nice, but it doesn't help if I am not a maintainer of the upstream project.

Since I haven't used it, I'm not sure, but it seems like it would also help avoid the case of "Can you squash this before I accept it?" leading to pointless delays and extra work.

Re: The Minimally-Nice Open Source Software Maintainer

#23

Post by vvanders »

This is great stuff and applies to more than just OSS. Working with vendors? Other parts of a large organization? A lot of the times the dynamics(or at least the learnings here) can be applied.

Kudos to the author, I'm sure that was no short amount of work to put together.

Re: The Minimally-Nice Open Source Software Maintainer

#24

Post by steveklabnik »

no_protocol wrote: post #22
steveklabnik wrote: post #19

Earlier quoted context omitted.

Have you seen https://github.com/blog/2247-improving-collaboration-with-fo... ?

Yes, that is very nice, but it doesn't help if I am not a maintainer of the upstream project. Since I haven't used it, I'm not sure, but it seems like it would also help avoid the case of "Can you squash this before I accept it?" leading to pointless delays and extra work.

Sorry, I thought you were speaking as a maintainer. You mean reviewing someone else's PR on a project you're not a maintainer of? Yeah that's "send a PR to their branch" right now.

> Does it help avoid the case of "Can you squash this before I accept it?" leading to pointless delays and extra work?

That's https://github.com/blog/2243-rebase-and-merge-pull-requests; lets you choose squash and/or rebase as you merge.

Re: The Minimally-Nice Open Source Software Maintainer

#25

Post by joe_the_user »

carapace wrote: post #11

One huge problem is that September never ended... ( https://en.wikipedia.org/wiki/Eternal_September ) What I mean is, there are lots of people who are not as smart as they think they are, and they won't STFU and RTFM, etc... Send not to know at whom the Torvalds curses, he curses at thee. Frankly, I think the author's original position was correct: Emphasize credit for authors of RFCs and you'll get fools authoring R…

Maybe I could put it another way. September 1993 ended, just not the way some people would have wanted it to.

The net has become a medium for everyone, not just a small enough group that this group could become acclimatized to a dominant discourse style (whatever the virtues might be of the Linus Torvalds "I will call you a fucking moron when you fail" school of discussion for a rarefied group). And given that, it is now necessary to have the standards of discourse for the net be the standards of discussion for society as a whole.

And sure, maybe being nice can produce a series of problems of its own. But it's now necessary to solves those problems while being nice.

Re: The Minimally-Nice Open Source Software Maintainer

#26

Post by jandrese »

crispyambulance wrote: post #4

This is just basic manners like your mother taught you. It is kind of sad that so much "social" advice on the internet consists of stuff people should have learned by the time they turned 12 years of age. In any case, I am glad the OP is making an effort in favor of gentility.

It's also important to remember that social norms are not consistent across the entire world. Some cultures are more deferential and others are more confrontational. On the Internet you are never sure exactly who the audience is, and in fact the audience is probably mixed. What seems like stern but helpful advice to one user comes across as browbeating to another. Very polite (deferential) people may not convey the seriousness of a situation to someone more used to direct speaking. Even inside of cultures there can be quite a lot of variety depending on factors like social standing, gender, and cultural identity.

This is why it is useful to talk about manners and customs even though it seems like child's play.

Re: The Minimally-Nice Open Source Software Maintainer

#27

Post by mwfunk »

Veen wrote: post #14
Cpoll wrote: post #7

> But before you fly off the chain, prove your undeniable superiority, and prove that they are wrong, let me suggest instead that you do something crazy, that you do the opposite: that you prove they are right. I'm a bit uneasy about this. If you spend your time agreeing with a suggestion that your initial reaction is to reject, you probably won't have the patience to go back and question it after the fact. You'll al…

> but I believe thinking critically is important I think you have to differentiate between thinking and communicating. Thinking comes first, unhindered by concerns for social niceties and hurt feelings. Then, you communicate by expressing what you've concluded in a way that does account for the fact that you're conveying a message to a human being, with all the baggage that entails.

I agree, at least in general- I think of critical thinking and communication as overlapping but very distinct skills.

I believe that if an idea hasn't been articulated yet (put into words, whether in writing or speech or thought), it hasn't been fully formed.

There's a saying that you don't truly understand something until you have to explain it to somebody else, and that's because it's not until you have to explain it to somebody else that you are forced to articulate the entire thing by serializing it (ugh) into words. Putting things into words nails down meaning in a way that can make logical problems or false assumptions much more obvious.

So, IMO communication is a two-pronged challenge. One challenge is articulating something that may have previously existed in a partially-formed state in the back of our heads. The other challenging is adapting that articulation to be as lossless and efficient as possible when directed at a specific audience. Communication is only successful if the signal is both successfully transmitted and successfully received. When we fail, it's easy to blame the audience, but IMO more often than not it's our own failure to read the room and we just don't like admitting that to ourselves. It's human nature to get defensive and use excuses like, "they were focused on nitpicking my words and not listening to my ideas!" That excuse in particular has become a huge red flag for me.

Re: The Minimally-Nice Open Source Software Maintainer

#28

Post by stestagg »

kibwen wrote: post #20
readams wrote: post #3

The worst maintainers are the ones who refuse to say no when they mean no or want to say no. I've seen maintainers waste weeks or months of a contributors time on work that they never intend to accept because they're trying to avoid confrontation up front.

I'd say that's a distinct skill that requires a different approach. Big projects have this problem less, because they have so many conflicting stakeholders and they get so much more practice rejecting random patches. But for little projects with one or few maintainers it's easy to look at every random contribution and be flattered that someone would bother to take the time to try and give back, which at the same time…

I like this approach, maybe they should try it for science and maths too.

Just post a list of all the major unsolved scientific questions, and then everyone will know not to bother with them, because they're unsolvable...

Re: The Minimally-Nice Open Source Software Maintainer

#29

Post by ori_b »

joe_the_user wrote: post #25
carapace wrote: post #11

One huge problem is that September never ended... ( https://en.wikipedia.org/wiki/Eternal_September ) What I mean is, there are lots of people who are not as smart as they think they are, and they won't STFU and RTFM, etc... Send not to know at whom the Torvalds curses, he curses at thee. Frankly, I think the author's original position was correct: Emphasize credit for authors of RFCs and you'll get fools authoring R…

Maybe I could put it another way. September 1993 ended, just not the way some people would have wanted it to. The net has become a medium for everyone, not just a small enough group that this group could become acclimatized to a dominant discourse style (whatever the virtues might be of the Linus Torvalds "I will call you a fucking moron when you fail" school of discussion for a rarefied group). And given that, it is…

Why? For the sake of playing devil's advocate: If I am not nice, maybe the people I don't want to interact with will go away and leave me alone.

Re: The Minimally-Nice Open Source Software Maintainer

#30

Post by ben_jones »

AndyNemmity wrote: post #18
no_protocol wrote: post #9

One thing I wish GitHub made easier is responding to a pull request with a patch rather than encouraging reviewers to type up a bunch of suggestions that the original submitter will have to turn into a patch themselves. If you have a better idea how to accomplish part of a suggested change, you can communicate that more clearly by making a patch and leaving a comment explaining why. GitHub should encourage this and a…

You could automate out half of feedback by automating a comment that says "add more tests" Even if you added tons of tests, you'll get add more tests. It almost makes more sense to write tests and hold them, so you can respond with them.

Or my personal favorite: auto-respond to feature requests with "PR welcome"
Post reply on HN