8 ms·

The Minimally-Nice Open Source Software Maintainer

224 points by aturon 9y ago

ori_b 9y ago
I 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.
readams 9y ago
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.
- kibwen 9y ago
  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 predisposes you to feeling like rejecting them would be some sort of betrayal. It's important to be magnanimous here when possible, but at the same time when they inevitably ask "why wasn't this accepted?" sometimes there simply isn't a more satisfying answer than "this doesn't fit with our unspoken philosophy of what the project should be". To use an example of a project I've contributed to, Dungeon Crawl Stone Soup has an explicit wiki page for "patches that we will not accept, so don't even bother asking": https://crawl.develz.org/wiki/doku.php?id=dcss:planning:wont_do https://crawl.develz.org/wiki/doku.php?id=dcss:planning:wont...
  - stestagg 9y ago
    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...
  - Karrot_Kream 9y ago
    Working with the DCSS maintainers is great though. I recently contributed some code to put FreeBSD support into DCSS, and it was great working with them!
crispyambulance 9y ago
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.
- hyperpape 9y ago
  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.
  - crispyambulance 9y ago
    You're right about that. It was my initial response and half-baked. I should have elaborated but now it is too late.
- farnsworth 9y ago
  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.
- jandrese 9y ago
  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.
otterley 9y ago
Contributors 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.
- pacaro 9y ago
  Everyone should take an improv class. Improv is about making offers, and responding to offers, and using that structure to build something unexpected So the aim is to avoid "no" which just closes everything down, "Yes, and…" or "Yes, but…" are powerful tools
- stinos 9y ago
  Contributors volunteer skilled labor In an ideal yet non-existing world that is true. In reality there are also contributors volunteering not-so-skilled labor resulting in quite some overhead for the maintainer. That doesnt make the other things you sais less of a good advice, but you almost make it sound like it's all flowers and sunshine.
- pc86 9y ago
  > rarely are they doing it for personal aggrandizement or to fulfill some philosophical mission. Sometimes. Spending hours tweaking a CoC or changing pronouns in documentation is not solving any problems and results in unnecessary back-and-forth, flame wars, HN posts, etc.
Cpoll 9y ago
> 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?"
- Veen 9y ago
  > 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.
  - mwfunk 9y ago
    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.
carapace 9y ago
Small sans-serif body text means you hate your readers. Making it grey means you really hate them.
- mh-cx 9y ago
  I dare to agree. The site is basically unreadable on mobile which is frustrating as the topic is really interesting.
- Veen 9y ago
  And to add insult to injury, for some reason Reader Mode in Safari doesn't appear to work on this site either (MacOS).
no_protocol 9y ago
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 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.
- jochakovsky 9y ago
  Could this be accomplished with a pull request into their feature branch?
  - no_protocol 9y ago
    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.
    - Bartweiss 9y ago
      It would be great to have "PR patches" as something handled gracefully by the web interface. Even if they're just branches under the hood, a "click to accept this change" feature on open PRs would be a nice way to encourage simple fixes.
- AndyNemmity 9y ago
  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.
carapace 9y ago
One huge problem is that September never ended... (https://en.wikipedia.org/wiki/Eternal_September 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 RFCs for the credit. Sheesh!
- kibwen 9y ago
  I agree that perverse incentives are possible, but I think that stance is a bit pessimistic. Being the author of an RFC grants you no social capital unless that RFC is good enough to get accepted (and if it's good enough to get accepted, then it's a good thing someone took the time to write it!). Additionally, the amount of social capital one receives from being known as the author of an RFC is very minor (especially since Rust RFCs only represent the beginning of the conversation, not the end, and the features any given RFC describes can change drastically between RFC and eventual stabilization, and god only knows how many people are responsible for the end result by that point). (There's only one accepted Rust RFC whose author I can name from memory, and that's only because it's an RFC that I didn't like. :P The knife cuts both ways!)
  - carapace 9y ago
    I agree with you. I'm erring on the side of exaggeration. The thing is there's a large, quiet, ad hoc network of people and it "computes": Who's paying attention? Who's doing the work? Keeping the normals from gumming up that network is very important, and calling [the wrong kind of] attention to it won't help... Cf. Tao Te Ching, chp. 3
- joe_the_user 9y ago
  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.
vvanders 9y ago
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.
pm24601 9y ago
Most open-source code is not managed very well (why should it be?) I always fire off an issue with an offer to patch. If no response, then no patch submitted even if I have a patch. I don't submit the patch because code moves on. A few commits later by someone else and the patch can no longer be cleanly applied. So I don't do the work on the patch if it will not be accepted. Also I don't do nit picky code clean up. For example, if someone wants 2 space indentation and I did 4 ... they can accept the patch and use their IDE with their formatting rules to fix such things.
bhntr3 9y ago
Best blog I've read in a long time! <3 > By consistently exhibiting a few simple behaviors, one can at least look like a kind and decent person. Maybe someday we all actually will be. The best thing about this is that we will! Mindset follows behavior. P.S. Am I doing it right? I'm actually terrible at this. But I wish I weren't.
kazinator 9y ago
All those things are basically like a software job, except for the part that you aren't paid. The skills to handle it are the same. In commercial development, you ideally have some layers between you and the customers. That depends on how large of an outfit you are and so on. How it works at Reasonably Big Co. is that all those requests from the end users don't go to you directly but to some customer support people (who are actually technical: they develop solutions and fix issues by actual coding; do not think "Microsoft customer support" here). You, in turn, support these people: but your manager should be coordinating that. If you are asked anything that would require significant development, you redirect to your manager; other than that, you help as much as you can without derailing your official work schedule. Secondly, if customers have some major request like for a major feature, support may defer them to "product management" to have that work put on the road-map for the next release or whatever. Product management doesn't bug you directly to develop anything. They negotiate with your managers to hammer out what is in scope, and from there a schedule is devised and so on. You end up with some tasks out of that schedule. Similar principles can be applied to your OSS project: you (and possibly the handful of other contributors) just have to wear all these hats yourselves. Here is the thing: those aforementioned support people independently produce solutions to problems. They check them into their own repos and they release that stuff to customers. Then later, customers want all that stuff carried forward in the software. So there is a tension: there are all these wild and wooly patches whipped up by support, of varying quality and they (or equivalent solutions in their place) have to be somehow integrated. The support people tend to say yes to customers to make them happy which isn't always best for the product. That is quite similar like when in OSS you are receiving complete patches from highly technical users who can code.
shoyer 9y ago
One of my favorite tricks as maintainer for a moderately popular project is asking every user to give themselves credit in the release notes, e.g., - Fixed a terrible bug that crashes lots of crashes. By John Smith. Contributors feel great seeing themselves get credit. New users see all the different contributors listed, giving themselves confidence that the project is well maintained. And finally, contributors are much less likely to forget to update the release notes!
cjCamel 9y ago
The Compliment Sandwich* is known to be a poor technique for providing criticism. It doesn't help the person you're criticising (people see straight through it) and it also negates the compliment. It also braces people for criticism next time you pay them a compliment. Worse still, it distracts from the message you are trying to convey. There is a way of being critical without making a person feel bad, by being factual and not making it personal, and by remembering that you are trying to help that person in some way. *Btw, we brits call it a shit sandwich :-D
- pc86 9y ago
  It's absolutely a shit sandwich, the sandwich is named for whatever's in the middle! :)

224 points by aturon 9y ago

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

readams 9y ago

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.

kibwen 9y ago
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 predisposes you to feeling like rejecting them would be some sort of betrayal. It's important to be magnanimous here when possible, but at the same time when they inevitably ask "why wasn't this accepted?" sometimes there simply isn't a more satisfying answer than "this doesn't fit with our unspoken philosophy of what the project should be". To use an example of a project I've contributed to, Dungeon Crawl Stone Soup has an explicit wiki page for "patches that we will not accept, so don't even bother asking": https://crawl.develz.org/wiki/doku.php?id=dcss:planning:wont_do https://crawl.develz.org/wiki/doku.php?id=dcss:planning:wont...
- stestagg 9y ago
  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...
- Karrot_Kream 9y ago
  Working with the DCSS maintainers is great though. I recently contributed some code to put FreeBSD support into DCSS, and it was great working with them!

crispyambulance 9y ago

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.

hyperpape 9y ago
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.
- crispyambulance 9y ago
  You're right about that. It was my initial response and half-baked. I should have elaborated but now it is too late.
farnsworth 9y ago
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.
jandrese 9y ago
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.

otterley 9y ago

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

pacaro 9y ago
Everyone should take an improv class. Improv is about making offers, and responding to offers, and using that structure to build something unexpected So the aim is to avoid "no" which just closes everything down, "Yes, and…" or "Yes, but…" are powerful tools
stinos 9y ago
Contributors volunteer skilled labor In an ideal yet non-existing world that is true. In reality there are also contributors volunteering not-so-skilled labor resulting in quite some overhead for the maintainer. That doesnt make the other things you sais less of a good advice, but you almost make it sound like it's all flowers and sunshine.
pc86 9y ago
> rarely are they doing it for personal aggrandizement or to fulfill some philosophical mission. Sometimes. Spending hours tweaking a CoC or changing pronouns in documentation is not solving any problems and results in unnecessary back-and-forth, flame wars, HN posts, etc.

Cpoll 9y ago

> 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?"

Veen 9y ago
> 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.
- mwfunk 9y ago
  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.

carapace 9y ago

Small sans-serif body text means you hate your readers. Making it grey means you really hate them.

mh-cx 9y ago
I dare to agree. The site is basically unreadable on mobile which is frustrating as the topic is really interesting.
Veen 9y ago
And to add insult to injury, for some reason Reader Mode in Safari doesn't appear to work on this site either (MacOS).

no_protocol 9y ago

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

jochakovsky 9y ago
Could this be accomplished with a pull request into their feature branch?
- no_protocol 9y ago
  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.
  - Bartweiss 9y ago
    It would be great to have "PR patches" as something handled gracefully by the web interface. Even if they're just branches under the hood, a "click to accept this change" feature on open PRs would be a nice way to encourage simple fixes.
AndyNemmity 9y ago
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.

carapace 9y ago

One huge problem is that September never ended... (https://en.wikipedia.org/wiki/Eternal_September 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 RFCs for the credit. Sheesh!

kibwen 9y ago
I agree that perverse incentives are possible, but I think that stance is a bit pessimistic. Being the author of an RFC grants you no social capital unless that RFC is good enough to get accepted (and if it's good enough to get accepted, then it's a good thing someone took the time to write it!). Additionally, the amount of social capital one receives from being known as the author of an RFC is very minor (especially since Rust RFCs only represent the beginning of the conversation, not the end, and the features any given RFC describes can change drastically between RFC and eventual stabilization, and god only knows how many people are responsible for the end result by that point). (There's only one accepted Rust RFC whose author I can name from memory, and that's only because it's an RFC that I didn't like. :P The knife cuts both ways!)
- carapace 9y ago
  I agree with you. I'm erring on the side of exaggeration. The thing is there's a large, quiet, ad hoc network of people and it "computes": Who's paying attention? Who's doing the work? Keeping the normals from gumming up that network is very important, and calling [the wrong kind of] attention to it won't help... Cf. Tao Te Ching, chp. 3
joe_the_user 9y ago
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.

vvanders 9y ago

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.

pm24601 9y ago

Most open-source code is not managed very well (why should it be?) I always fire off an issue with an offer to patch. If no response, then no patch submitted even if I have a patch. I don't submit the patch because code moves on. A few commits later by someone else and the patch can no longer be cleanly applied. So I don't do the work on the patch if it will not be accepted. Also I don't do nit picky code clean up. For example, if someone wants 2 space indentation and I did 4 ... they can accept the patch and use their IDE with their formatting rules to fix such things.

bhntr3 9y ago

Best blog I've read in a long time! <3 > By consistently exhibiting a few simple behaviors, one can at least look like a kind and decent person. Maybe someday we all actually will be. The best thing about this is that we will! Mindset follows behavior. P.S. Am I doing it right? I'm actually terrible at this. But I wish I weren't.

kazinator 9y ago

All those things are basically like a software job, except for the part that you aren't paid. The skills to handle it are the same. In commercial development, you ideally have some layers between you and the customers. That depends on how large of an outfit you are and so on. How it works at Reasonably Big Co. is that all those requests from the end users don't go to you directly but to some customer support people (who are actually technical: they develop solutions and fix issues by actual coding; do not think "Microsoft customer support" here). You, in turn, support these people: but your manager should be coordinating that. If you are asked anything that would require significant development, you redirect to your manager; other than that, you help as much as you can without derailing your official work schedule. Secondly, if customers have some major request like for a major feature, support may defer them to "product management" to have that work put on the road-map for the next release or whatever. Product management doesn't bug you directly to develop anything. They negotiate with your managers to hammer out what is in scope, and from there a schedule is devised and so on. You end up with some tasks out of that schedule. Similar principles can be applied to your OSS project: you (and possibly the handful of other contributors) just have to wear all these hats yourselves. Here is the thing: those aforementioned support people independently produce solutions to problems. They check them into their own repos and they release that stuff to customers. Then later, customers want all that stuff carried forward in the software. So there is a tension: there are all these wild and wooly patches whipped up by support, of varying quality and they (or equivalent solutions in their place) have to be somehow integrated. The support people tend to say yes to customers to make them happy which isn't always best for the product. That is quite similar like when in OSS you are receiving complete patches from highly technical users who can code.

shoyer 9y ago

One of my favorite tricks as maintainer for a moderately popular project is asking every user to give themselves credit in the release notes, e.g., - Fixed a terrible bug that crashes lots of crashes. By John Smith. Contributors feel great seeing themselves get credit. New users see all the different contributors listed, giving themselves confidence that the project is well maintained. And finally, contributors are much less likely to forget to update the release notes!

cjCamel 9y ago

The Compliment Sandwich* is known to be a poor technique for providing criticism. It doesn't help the person you're criticising (people see straight through it) and it also negates the compliment. It also braces people for criticism next time you pay them a compliment. Worse still, it distracts from the message you are trying to convey. There is a way of being critical without making a person feel bad, by being factual and not making it personal, and by remembering that you are trying to help that person in some way. *Btw, we brits call it a shit sandwich :-D

pc86 9y ago
It's absolutely a shit sandwich, the sandwich is named for whatever's in the middle! :)