How to get an open source community to be interested in helping you(snoyman.com)
snoyman.com
How to get an open source community to be interested in helping you
https://www.snoyman.com/blog/2017/10/manipulating-maintainers
49 comments
"I'm going to have to strip off the extraneous bits until I'm staring the problem in the face. Why should I spend my time doing that, when you—the person asking for help—could be?"
Oh, the dozens and dozens of times I solved my own problem while making it reproducible, before actually filing the report!
Oh, the dozens and dozens of times I solved my own problem while making it reproducible, before actually filing the report!
Much like Rubber Ducking: https://en.wikipedia.org/wiki/Rubber_duck_debugging
On the other hand, If I as a user run into some trivial bug and go "hey feature XYZ is obviously broken" I get rather annoyed at repo maintainers who think I am then somehow required to debug the problem for them.
This, or the report template itself suggests troubleshooting steps that I hadn't considered, and solved my problem that way.
These are great tidbits for how a contributor can get the attention of a maintainer but I think these tips also inform well on how a maintainer can get more contributors.
Recently I started a new project and got 7 contributors in a week - more than I've gotten for any project ever. [1] I think its partly due to hacktoberfest but also because I realized I can't waste a contributor's time. I made issues with descriptions of exactly what should be done - where in the code they could introduce edits, and what kind of dependencies people could use to implement, etc. Though I could have done myself, I didn't have to and I also got to see some ingenuity of other people!
[1]: https://github.com/schollz/croc/graphs/contributors
Recently I started a new project and got 7 contributors in a week - more than I've gotten for any project ever. [1] I think its partly due to hacktoberfest but also because I realized I can't waste a contributor's time. I made issues with descriptions of exactly what should be done - where in the code they could introduce edits, and what kind of dependencies people could use to implement, etc. Though I could have done myself, I didn't have to and I also got to see some ingenuity of other people!
[1]: https://github.com/schollz/croc/graphs/contributors
A recent Twitter discussion/checklist on attracting a community as a maintainer:
https://twitter.com/sehurlburt/status/921921604140937216
https://twitter.com/sehurlburt/status/921921604140937216
This is a cool project.
OT, but Michael is a great guy. At LambdaConf, he got lunch with me specifically to spend time explaining monad transformers, just because we were chatting and I expressed confusion. Had no idea who he was. Later learned he's the Yesod guy, which is the main Haskell web framework. I'm always grateful when the big players in some domain make themselves as approachable as he does.
Yesod (most typesafe webframework), Stack (quick to become a very popular build/install tool in Haskell land), conduit (a lib/ecosystem for dealing with data streams), Stackage (publishes sets of packages know to work well together). He's currently Director of Engineering at FP Complete.
Here the packages he's a maintainer for on Hackage:
https://hackage.haskell.org/user/MichaelSnoyman
Here the packages he's a maintainer for on Hackage:
https://hackage.haskell.org/user/MichaelSnoyman
As the sole maintainer of a pretty big repo, these are all super helpful. Another is that, if the project in question is compiled, add in a gdb trace. It's often the difference between "I know exactly what this is and I'll do it now to get it over with." and "There's about three+ ways this could be happening, I'll check it out later."
My experience working on an OSS project has been that the biggest thing missing from the bug-reporter side isn't phrasing or planning, just dedication. If someone doesn't post a useful initial bug report, we can still probably work our way there if they keep pinging the thread or follow whatever instructions come out of the maintenance side of things. OTOH, if I can't see that an issue is actively causing someone pain, it's way easier for it to fall off my radar. Apathy slows down resolution far more often than antipathy.
http://www.catb.org/esr/faqs/smart-questions.html
ESR did it better, imho :-)
ESR did it better, imho :-)
There's some marginally useful content buried in that, but wrapped in a pervasive and unpleasant position of "the person you're asking is way more important than you, lowly questioner", and many excuses attempting to justify elitism.
I much prefer Julia Evans: https://jvns.ca/blog/good-questions/ and https://jvns.ca/blog/answer-questions-well/
I much prefer Julia Evans: https://jvns.ca/blog/good-questions/ and https://jvns.ca/blog/answer-questions-well/
I had never seen Julia Evans' writing on the topic but have read ESR's many times. It looks like Evans' guide is mostly geared towards being considerate of the other person and ESR's is mostly geared towards collecting the appropriate information beforehand and phrasing the question the right way. Both are extremely important for effective question asking.
Regarding the "lowly questioner" dynamic, look at it this way: if you're asking someone a question about their software, you're seeking to extract time from someone in order to extract value from something that they created. Be humble.
Regarding the "lowly questioner" dynamic, look at it this way: if you're asking someone a question about their software, you're seeking to extract time from someone in order to extract value from something that they created. Be humble.
> It looks like Evans' guide is mostly geared towards being considerate of the other person and ESR's is mostly geared towards collecting the appropriate information beforehand and phrasing the question the right way.
https://jvns.ca/blog/good-questions/ covers both of those topics in detail, in my opinion.
https://jvns.ca/blog/good-questions/ covers both of those topics in detail, in my opinion.
> "the person you're asking is way more important than you, lowly questioner"
I don't think it's saying that. It's just saying "the person you're asking owes you nothing, is probably very busy at best, and may be a self-important jerk at worst, this is probably the most effective way to ask them for help."
I don't think it's saying that. It's just saying "the person you're asking owes you nothing, is probably very busy at best, and may be a self-important jerk at worst, this is probably the most effective way to ask them for help."
It also, in multiple places, seems to say "but they're not really a self-important jerk, they're just defensive of their time". And in general, it defends elitism and excuses unpleasant behavior.
(There's nothing wrong with being defensive of your time. There's something very wrong with being a jerk about it.)
(There's nothing wrong with being defensive of your time. There's something very wrong with being a jerk about it.)
I'd written a reply to someone commenting on the description of "elitism", but that comment was deleted. So, instead, here's a partial list of issues (both elitist and otherwise), and reasons to not link to or advocate that particular document.
Quoting directly from the document:
> you are one of the idiots we are talking about
> leave us alone and everybody will be happier
> What we are, unapologetically, is hostile to
> We call people like this “losers” (and for historical reasons we sometimes spell it “lusers”).
> J. Random Hacker is quite likely to reply with a uselessly literal answer while thinking “Stupid question...”, and hoping the experience of getting what you asked for rather than what you needed will teach you a lesson.
> Stupid:
> we can't be bothered
> will make you come off like a giggly teenage girl, which is not generally a good idea unless you are more interested in sex than answers
The entire section entitled "RTFM and STFW: How To Tell You've Seriously Screwed Up", especially things like:
> You shouldn't be offended by this; by hacker standards, your respondent is showing you a rough kind of respect simply by not ignoring you. You should instead be thankful for this grandmotherly kindness.
> The same place I'd find it, fool
> J. Random Hacker's response to this is likely to be “Right. Do you need burping and diapering, too?”
> While muttering RTFM is sometimes justified
(no, it isn't)
- Terms like "ruthless" used as praise.
- Numerous attempts to praise lack of basic decency and excuse bad behavior in the community.
- A pervasive "us" and "you" approach to othering the lowly petitioner, despite claiming to want to welcome them.
The above is a partial list of reasons why not to recommend that particular document, and why to seek out and recommend better ones. I've seen people recommend this particular document while simultaneously attempting to excuse it; better would be to write it off as a hopeless bit of elitist historical interest, recommend better documents that already exist, and update any such documents to include any useful information that they might lack.
Quoting directly from the document:
> you are one of the idiots we are talking about
> leave us alone and everybody will be happier
> What we are, unapologetically, is hostile to
> We call people like this “losers” (and for historical reasons we sometimes spell it “lusers”).
> J. Random Hacker is quite likely to reply with a uselessly literal answer while thinking “Stupid question...”, and hoping the experience of getting what you asked for rather than what you needed will teach you a lesson.
> Stupid:
> we can't be bothered
> will make you come off like a giggly teenage girl, which is not generally a good idea unless you are more interested in sex than answers
The entire section entitled "RTFM and STFW: How To Tell You've Seriously Screwed Up", especially things like:
> You shouldn't be offended by this; by hacker standards, your respondent is showing you a rough kind of respect simply by not ignoring you. You should instead be thankful for this grandmotherly kindness.
> The same place I'd find it, fool
> J. Random Hacker's response to this is likely to be “Right. Do you need burping and diapering, too?”
> While muttering RTFM is sometimes justified
(no, it isn't)
- Terms like "ruthless" used as praise.
- Numerous attempts to praise lack of basic decency and excuse bad behavior in the community.
- A pervasive "us" and "you" approach to othering the lowly petitioner, despite claiming to want to welcome them.
The above is a partial list of reasons why not to recommend that particular document, and why to seek out and recommend better ones. I've seen people recommend this particular document while simultaneously attempting to excuse it; better would be to write it off as a hopeless bit of elitist historical interest, recommend better documents that already exist, and update any such documents to include any useful information that they might lack.
I can handle a bit of rough and tumble no-nonsense language, personally. I'd like to think most folks attempting to build/repair/maintain systems built by other people can too. Disregarding this document because it's not hand-holding enough would be, IMHO, throwing the baby out with the bath-water.
> rough and tumble no-nonsense language
This is an inaccurate and dismissive description. This document is actively hostile, and revels in its hostility. It's propagating a perspective that it's acceptable to deride and denigrate newbies, that it's acceptable to be hostile and toxic and unwelcoming, and so on. It gleefully celebrates, or at the very least excuses, people who throw around "RTFM" and "STFU noob" and "UTSL". Propagating this document encourages people to think such behavior is a good idea.
We can, and should, build better hacker communities, and this document has no place in those.
> personally. I'd like to think most folks attempting to build/repair/maintain systems built by other people can too.
You might like to think that, but that assumption excludes many people from the community, in a self-perpetuating vicious cycle (where "vicious" is a particularly appropriate word). It creates communities that exclude people who are not like you. And even those who can should not have to. I can cope with such people, but it's painful and draining, so I spend more time in communities where such hostility is not accepted.
You might find if you spend time in such communities that you may enjoy them more as well. Or perhaps not, but either way don't make things worse for others.
The right response to such hostility is "we don't do that here".
This is an inaccurate and dismissive description. This document is actively hostile, and revels in its hostility. It's propagating a perspective that it's acceptable to deride and denigrate newbies, that it's acceptable to be hostile and toxic and unwelcoming, and so on. It gleefully celebrates, or at the very least excuses, people who throw around "RTFM" and "STFU noob" and "UTSL". Propagating this document encourages people to think such behavior is a good idea.
We can, and should, build better hacker communities, and this document has no place in those.
> personally. I'd like to think most folks attempting to build/repair/maintain systems built by other people can too.
You might like to think that, but that assumption excludes many people from the community, in a self-perpetuating vicious cycle (where "vicious" is a particularly appropriate word). It creates communities that exclude people who are not like you. And even those who can should not have to. I can cope with such people, but it's painful and draining, so I spend more time in communities where such hostility is not accepted.
You might find if you spend time in such communities that you may enjoy them more as well. Or perhaps not, but either way don't make things worse for others.
The right response to such hostility is "we don't do that here".
Check your privilege. While you may have the luxury, political cachet, or just plain old luck at your job to pooh-pooh whatever open source libraries, applications, or frameworks that don't meet your arbitrary definition of saccharine civility, the rest of us out in the real working world have far more pedestrian concerns.
The ideals you've posited sound pleasant initially, but they bear little resemblance to being able to do real work in the messy, impatient, human-infested world others live in. Would it be nice to eschew the linux kernel, or the openbsd community, because a large fraction of those folks meet the ESR 'busy hacker with attitude' definition? Sure. Would it be career-killing to say "Linus/Theo were curt with me, _how wude_, let me agonize over it on my Tumblr and waste dev cycles finding another kernel/crypto library/whatever"? Absolutely.
ESR's guide is pragmatic, and far more effective at solving the real problem in front of the questioner, than the "pout and shun" methodology you've espoused.
The ideals you've posited sound pleasant initially, but they bear little resemblance to being able to do real work in the messy, impatient, human-infested world others live in. Would it be nice to eschew the linux kernel, or the openbsd community, because a large fraction of those folks meet the ESR 'busy hacker with attitude' definition? Sure. Would it be career-killing to say "Linus/Theo were curt with me, _how wude_, let me agonize over it on my Tumblr and waste dev cycles finding another kernel/crypto library/whatever"? Absolutely.
ESR's guide is pragmatic, and far more effective at solving the real problem in front of the questioner, than the "pout and shun" methodology you've espoused.
I am well aware that several critical projects have incredibly awful and hostile communities. I'm also aware that a subset of people in those communities actually attempt to claim that their hostility is a feature. That's a bug, and useful to warn people about, and to attempt to fix, and to not copy in any new community. It's not a thing to revel in, excuse, and encourage, lest we end up with more.
You seem to be reading more into that statement than I've actually said. You're also attempting to ascribe a ridiculously patronizing tone that is of course easy to argue against, having been artificially constructed for that purpose rather than representing any actual position I've stated. I didn't say "don't use Linux because LKML is awful"; that would indeed be counterproductive. I'm saying "make new communities more friendly and welcoming than LKML, and don't encourage or excuse being awful to others".
Are you actually attempting to claim the document has no issues at all? Or are you simply trying to claim that despite its issues the document also contains useful information? I'm not arguing against the latter, simply stating that that's a good reason to create and propagate new documents that don't have those issues. If you're trying to claim the former, you've done nothing to actually support that position or reply to the detailed list of such issues.
You seem to be reading more into that statement than I've actually said. You're also attempting to ascribe a ridiculously patronizing tone that is of course easy to argue against, having been artificially constructed for that purpose rather than representing any actual position I've stated. I didn't say "don't use Linux because LKML is awful"; that would indeed be counterproductive. I'm saying "make new communities more friendly and welcoming than LKML, and don't encourage or excuse being awful to others".
Are you actually attempting to claim the document has no issues at all? Or are you simply trying to claim that despite its issues the document also contains useful information? I'm not arguing against the latter, simply stating that that's a good reason to create and propagate new documents that don't have those issues. If you're trying to claim the former, you've done nothing to actually support that position or reply to the detailed list of such issues.
[deleted]
That is a classic.
I re-read it every few years, and if we all spent the time to ask smart questions in every sphere of our lives, we'd all be better off. It's hard to do though, because it demands we expect more of ourselves. Sometimes it's easy to just post a question to the ether than to do the hard work of investigation/research needed to ask a smart one.
I re-read it every few years, and if we all spent the time to ask smart questions in every sphere of our lives, we'd all be better off. It's hard to do though, because it demands we expect more of ourselves. Sometimes it's easy to just post a question to the ether than to do the hard work of investigation/research needed to ask a smart one.
He is indeed the master. Much of his advice is timeless. I find myself going back to things every so often. Especially the Eric Conspiracy, which most certainly does not exist.
http://www.catb.org/esr/ecsl/
http://www.catb.org/esr/ecsl/
I like Simon Tatham's "How to Report Bugs Effectively" - https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
By not trying to window-shop? Aka, posting wishes disguised as suggestions.
My all time favorite- asking for a feature that is already existing, not taking time to search the documentation, then when somebody duplicates the information for you (basically becoming your free of charge search engine) - you dont thank him, but ask for a implementation (basically hiring a programmer for free)- once that doesent happen, you are never heard of again.
And that above is the norm in Open source community. Those hostility arise, because there is a constant stream of clueless users doing the crybaby on forums. Which is why man open source devs retreat to irc and only answer your question if you lurk for a day and post a little history detailing your own investment.
My all time favorite- asking for a feature that is already existing, not taking time to search the documentation, then when somebody duplicates the information for you (basically becoming your free of charge search engine) - you dont thank him, but ask for a implementation (basically hiring a programmer for free)- once that doesent happen, you are never heard of again.
And that above is the norm in Open source community. Those hostility arise, because there is a constant stream of clueless users doing the crybaby on forums. Which is why man open source devs retreat to irc and only answer your question if you lurk for a day and post a little history detailing your own investment.
The "XY Problem" link[1] has an authentic-sounding and hilarious impression of a developer being a jerks to a newcomer.
A quick analysis of "Example 1":
* developer has already figured out that the person almost certainly means to get the extension, but they then inexplicably post the likely irrelevant answer that blithely returns the last three characters. (More on that below...)
* developer uses caps-- meant to convey that they are YELLING at the questioner-- which is unwarranted and pointlessly aggressive
* developer is obviously annoyed by questioner taking too many steps to get to a proper statement of their problem. But after the developer states the problem properly and the questioner confirms it, the developer wastes a step in their own response to demand that the questioner obtain an arbitrary level of knowledge before they state future problems. I write "arbitrary" because the developer has apparently decided that the questioner should have already known that a) a file extension is called a file extension and b) file extensions don't always contain three characters. But the implication is that a questioner armed with this increased level of knowledge (and who would have therefore Google'd the answer more easily) strangely would be more deserving of receiving an answer than someone who obviously sought out the help of a fellow human being because they didn't know what to search for. That's a bizarre (and frankly anti-social) line of reasoning.
* developer uses a mean-spirited adjective "blindly", ostensibly to hurt the newcomer's feelings. But this is my favorite part-- the developer has already shown that they were nearly certain that the questioner meant to ask for concept they were unable to name-- an extension. (Plus having that confirmed by the questioner.) So for the insult to work here, the developer refers back to their own irrelevant example, calling that "blindly grabbing three characters," and using sleight of hand to reinterpret that as the initial query. All this after having already confirmed the questioner's actual problem!
That shows an impressive level of premeditation to be a jerk-- that is, setting up an irrelevant answer in order to heighten the language for an insult in a later response.
I sure hope this example response doesn't really reflect the current communication style of FLOSS devs.
1) http://xyproblem.info/
A quick analysis of "Example 1":
* developer has already figured out that the person almost certainly means to get the extension, but they then inexplicably post the likely irrelevant answer that blithely returns the last three characters. (More on that below...)
* developer uses caps-- meant to convey that they are YELLING at the questioner-- which is unwarranted and pointlessly aggressive
* developer is obviously annoyed by questioner taking too many steps to get to a proper statement of their problem. But after the developer states the problem properly and the questioner confirms it, the developer wastes a step in their own response to demand that the questioner obtain an arbitrary level of knowledge before they state future problems. I write "arbitrary" because the developer has apparently decided that the questioner should have already known that a) a file extension is called a file extension and b) file extensions don't always contain three characters. But the implication is that a questioner armed with this increased level of knowledge (and who would have therefore Google'd the answer more easily) strangely would be more deserving of receiving an answer than someone who obviously sought out the help of a fellow human being because they didn't know what to search for. That's a bizarre (and frankly anti-social) line of reasoning.
* developer uses a mean-spirited adjective "blindly", ostensibly to hurt the newcomer's feelings. But this is my favorite part-- the developer has already shown that they were nearly certain that the questioner meant to ask for concept they were unable to name-- an extension. (Plus having that confirmed by the questioner.) So for the insult to work here, the developer refers back to their own irrelevant example, calling that "blindly grabbing three characters," and using sleight of hand to reinterpret that as the initial query. All this after having already confirmed the questioner's actual problem!
That shows an impressive level of premeditation to be a jerk-- that is, setting up an irrelevant answer in order to heighten the language for an insult in a later response.
I sure hope this example response doesn't really reflect the current communication style of FLOSS devs.
1) http://xyproblem.info/
False XP Problem is a pet peive of mine actually. Personally, I downvote any answer on e.g. Stack Overflow that doesn't answer the question asked. The proper way to respond to any technical question, IMO, is first answer it exactly as ask if you can (if you don't, then don't answer). After that, you may optionally ask what the person is trying to do and offer your expertise.
The issue I run into is this: I work in the enterprise environment. I have a lot of experience but sometimes I'm forced into doing something seemingly stupid that you would normally never want to do (obviously more complicated than the silly "last 3 characters" problem). So I ask on SO giving as little detail as possible, purposely because I'm hoping to avoid a bunch of wasted time with "but you don't need to do that you can do solution A", where solution A is a solution I already wanted to do but was unable because of some reality of the company I work for (and no, I can't download or install anything and I won't be able to change that). All the obvious solutions will be this way. What I actually needed was what I asked and I had to ask precisely because I also never normally want to do this so I don't know how.
I find the kind of answers that some people advocate for extremely arrogant. By answering e.g. an SO question by answering something that wasn't asked you (a) assume you know more than the person asking (you may, or you may not) and (b) assume there will never be another user anywhere that will actually need the answer to the question that was asked. I get hit by (b) the most: I put my question into google, I actually find an SO question that I need the answer to but some jerk explained the user wanted something else, answered that and then, of course, the thread died.
The issue I run into is this: I work in the enterprise environment. I have a lot of experience but sometimes I'm forced into doing something seemingly stupid that you would normally never want to do (obviously more complicated than the silly "last 3 characters" problem). So I ask on SO giving as little detail as possible, purposely because I'm hoping to avoid a bunch of wasted time with "but you don't need to do that you can do solution A", where solution A is a solution I already wanted to do but was unable because of some reality of the company I work for (and no, I can't download or install anything and I won't be able to change that). All the obvious solutions will be this way. What I actually needed was what I asked and I had to ask precisely because I also never normally want to do this so I don't know how.
I find the kind of answers that some people advocate for extremely arrogant. By answering e.g. an SO question by answering something that wasn't asked you (a) assume you know more than the person asking (you may, or you may not) and (b) assume there will never be another user anywhere that will actually need the answer to the question that was asked. I get hit by (b) the most: I put my question into google, I actually find an SO question that I need the answer to but some jerk explained the user wanted something else, answered that and then, of course, the thread died.
Absolutely, this is why I rarely use stack overflow anymore. This attitude exists in all programming languages, even many of the stack exchange sites, like mathematics. I wish there was a direct way of saying it: "Believe me, I am smarter than you think I am. These cop-out solutions you're proposing have all been considered, but if I could find any way of solving my direct problem, it would be better than any other alternative."
I also run into this problem when asking on SO. Even if you write in the question "I've already ruled out ... as a possible solution" you still get people trying to argue about it. I'd rather they ignore the question...
No disagreement that the developer is unnecessarily hostile.
That said, your reading is not very charitable. Mine was:
* Developer reflectively responds to the question as stated
* Developer then thinks "wait a minute, why 3 characters?"
* Developer assumes questioner knows that extensions are called extensions, because "everyone" (certainly "everyone in a tech IRC channel") knows. Speaking from personal experience, this is an easy trap to fall into
* The response of the questioner ("yes", rather than "maybe, what's an extension?") confirms that assumption in the developer's mind
That said, your reading is not very charitable. Mine was:
* Developer reflectively responds to the question as stated
* Developer then thinks "wait a minute, why 3 characters?"
* Developer assumes questioner knows that extensions are called extensions, because "everyone" (certainly "everyone in a tech IRC channel") knows. Speaking from personal experience, this is an easy trap to fall into
* The response of the questioner ("yes", rather than "maybe, what's an extension?") confirms that assumption in the developer's mind
This happens in real life in software development frequently enough that thinking back on my career I can mentally replay the XY problem chat log as multiple IRL conversations I've overheard between a senior and junior developer without changing much.
I think it doesn't only stem from OSS communities, but is some sort of innate tendency in the types of people who get into software and IT, which dictates that community culture unchecked can become a contest of derision, one-upsmanship, and as you put it, impressive levels of premeditated jerk-ness. I don't know if it comes from the (apparently) increased levels of antisocial personalities in software, or insecurity, or maybe a more base, primal urge to haze the newcomers unnecessarily.
I think it doesn't only stem from OSS communities, but is some sort of innate tendency in the types of people who get into software and IT, which dictates that community culture unchecked can become a contest of derision, one-upsmanship, and as you put it, impressive levels of premeditated jerk-ness. I don't know if it comes from the (apparently) increased levels of antisocial personalities in software, or insecurity, or maybe a more base, primal urge to haze the newcomers unnecessarily.
> I sure hope this example response doesn't really reflect the current communication style of FLOSS devs.
Not as pervasive as it used to be, but sadly still present in some places, particularly in communities that don't go out of their way to discourage it.
Personally, I would suggest https://jvns.ca/blog/answer-questions-well/ and https://jvns.ca/blog/good-questions/ , the first of which was specifically written to address the lack of availability of documents talking about the issue without that kind of newbie-unfriendly elitism.
Not as pervasive as it used to be, but sadly still present in some places, particularly in communities that don't go out of their way to discourage it.
Personally, I would suggest https://jvns.ca/blog/answer-questions-well/ and https://jvns.ca/blog/good-questions/ , the first of which was specifically written to address the lack of availability of documents talking about the issue without that kind of newbie-unfriendly elitism.
For the XY problem I kind of think it's fine to just help them with Y and let them discover Y wasn't an appropriate solution to X themselves. They might need help again with X, but they'll probably learn more from doing Y and discovering why Y was wrong themselves.
There's an old "ha ha, only serious" joke. If you go to a Linux forum and ask for help fixing your WiFi driver, everyone will ignore you. If, instead, you say "Linux sucks, you can't even get a f&$ing WiFi driver working!" thousands of people will solve the problem for you.*
This is 100% accurate. There is no better way to get assistance with HiDPI tweaking on a Linux desktop than to go onto a subreddit and bash your DE of choice, complaining about its lack of HiDPI support.
This is 100% accurate. There is no better way to get assistance with HiDPI tweaking on a Linux desktop than to go onto a subreddit and bash your DE of choice, complaining about its lack of HiDPI support.
A good summary.
I've also found that timing can be important. Basically: don't ask on Fri at 3:30.
I've also found that timing can be important. Basically: don't ask on Fri at 3:30.
You might be right statistically, but many of my acquaintances and I work on open source beginning Friday and ending Sunday night. It depends on the project. If it's an open source web server, you're right. If it's a tiling window manager, the opposite is true.
Fair. But timing matters.
High usage attracts higher level developers. The motivation created by your software being used by a large community of people is, in my opinion, the most portant thing when contributing. Sometimes it is easy, like adding a few flags to fpc, sometimes it is a bit more tricky, like adding utf-8 support to an IDE which lacks it.
[deleted]
Agreed. This is why open source works: success brings in more resources (a positive feedback loop). It's the same thing that happens in for-profit companies.
[deleted]
I’d advise removing the first paragraph. It’ll trigger some readers into rolling their eyes and leaving
Explain what you want to do in twenty seconds, or less.
Great post, definitely these are the things that make for a great participating in an OSS project.
Unfortunately, the folks who spew out impatient, one liner bug reports are exactly the folks who will never read such a blog post, or anything else for that matter. They won't even read the ALL BOLDFACE bug posting instructions I put up that tell them to post a usage example and don't just show a line of code you think should change.
I've had many days ruined by naive idiots who think I work for them or something, and it is an ongoing, multi-year practice to learn how to not escalate and how to not have your day ruled by such people.
In case I'm not getting downmodded here enough, I'll add that users/nicknames that seem to identify as female never have any of these issues - users that identify as female always come very well prepared with great test cases and all the up front research done. More and more the issue of "decency" seems to pervade all areas of human interaction as we've descended into such a non-decent era.