The Minimally-Nice Open Source Software Maintainer
brson.github.io
The Minimally-Nice Open Source Software Maintainer
1–10 of 61 posts
Re: The Minimally-Nice Open Source Software Maintainer
#2I think I'd get annoyed working with people who respond like this. Except for the part about fast response times -- I like that.
I don't like guessing people's intent. I don't like it when people are evasive about saying no, wasting both my time and theirs.
Re: The Minimally-Nice Open Source Software Maintainer
#3The 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.
Re: The Minimally-Nice Open Source Software Maintainer
#4This 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.
Re: The Minimally-Nice Open Source Software Maintainer
#5This 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.
I think it's basic manners that when someone writes a long piece about a subject they're struggling with, you shouldn't just respond that it's "stuff people should have learned by the time they turned 12 years of age".
It's basic manners, but we all struggle with basic manners sometimes, especially on the Internet.
Re: The Minimally-Nice Open Source Software Maintainer
#6Contributors volunteer skilled labor that can help a project be even better. The worst thing a maintainer can do is dissuade them from helping.
A good rule of thumb is to assume positive intent from contributors. People who are requesting changes are trying to solve problems; rarely are they doing it for personal aggrandizement or to fulfill some philosophical mission.
One thing that really upsets me when I propose changes -- especially when they're accompanied by code -- is getting a thumbs-down from (or, even worse, an issue closed by) a maintainer, without any constructive feedback as to how to resolve their concerns. I can work with someone who can inform me about their concerns or the weaknesses of my proposal, and who says, "yes, but...," but I can't work with someone who just says "no."
In my own projects, I have a rule of thumb: I never close an issue without the consent of the submitter. I try to ensure I've either convinced them that there's a better way to do what they're trying to achieve; I've resolved their problem as best I can; or I simply don't have the resources to give them a proper resolution.
Re: The Minimally-Nice Open Source Software Maintainer
#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 also possibly 'brainwash' yourself into thinking it's a good idea?
I agree that you shouldn't knee-jerk into rejecting an idea, but I believe thinking critically is important. Take the opposite side, but do it civilly. Come up with counter-examples, but phrase them constructively: "have you considered this problem, do you think it's an issue, can you think of a solution?"
Re: The Minimally-Nice Open Source Software Maintainer
#8Small sans-serif body text means you hate your readers. Making it grey means you really hate them.
Re: The Minimally-Nice Open Source Software Maintainer
#9One 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 allow the submitter some interface to easily incorporate that patch into his PR.
This is especially useful in situations where the only changes are in documentation or writing rather than code. Dealing with a dozen responses of "s/topy/typo/" should be as simple as clicking a few buttons to accept all the corrections. It would be less work for both sides.
Re: The Minimally-Nice Open Source Software Maintainer
#10This 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.
The basic manners that you learned early on for interacting with people face-to-face don't scale to interacting with many many people in an issue tracker every day, anonymously, asynchronously, over the internet. It's a weird circumstance that we didn't evolve to handle, so I think it makes sense to break it down and carefully look at how to handle these situations efficiently and positively.