A couple of users encouraged me in good faith to write this. I was a bit skeptical, but today I figured, why not. Here goes.

I want to make an argument for why certain tags, , etc, are treated differently at Stack Overflow, and, perhaps more controversially, must be treated differently. I think the approach I am suggesting is pragmatic, doesn't really break SO's design, is consistent with SO's remit, and most importantly, will resolve so much of the conflict seen.

Hear me out.

Send me teh codez tags

I am going to focus on sed mostly because I know sed very well, but similar considerations extend to other tags like , , , , etc.

These tags have been described in comments here as send me teh codez tags. That is, the questions often can't be broken down further; it is hard if not impossible to google for the answers; the alternative to asking at SO would be to just fully read the manuals; no one honestly expects the OPs to actually do that; there is often no real way to reduce these questions to minimal, complete, verifiable examples anyway; sometimes it is difficult to put into words what you're trying to do if you don't understand the language; showing what you tried already doesn't necessarily add much to the question; and, besides. These queues have at least 10 competitive, rep-huntin' regulars who are going to answer the questions anyway within minutes of posting, if not within seconds.

So what can we do?

One user suggested cynically that these tags need to be recognised as "lost cause" tags. Another put it more positively and said that because the queues help lots of people get their jobs done, it could be that the regulars have more insight here, and maybe all the rep-huntin' isn't the big problem it appears to be. Yet another Meta hardliner suggested that, no, the problem begins and ends with the disobedient rep-huntin' regulars who simply refuse to enforce the site's rules, because they care about rep.

Why these questions are different

Inherently different languages

In the case of , and I think certainly too, and probably all the others, these questions are inherently different to regular higher-level programming language questions.

Sed, specifically, is a tiny, Turing-complete programming language. It consists of a regular expression engine; about 30 builtin single-letter functions; 2 buffers; and a very simple grammar.

Understanding why sed needs to be treated differently begins with recognising that sed is tiny, relative to other languages, and every question about it has been asked before. Many times.

Additionally, sed lacks features familiar to other programmers like variables, user defined functions, libraries etc. Solving problems in sed involves thinking about problems in a very different way.

The end result of this is consumers of sed scripts typically want one-line scripts that are just known to work. They often don't even want to know how they work (even if a good answer should explain it all the same).

Almost every possible question has been asked before

After 10 years (SO's age), I expect that every sed question is duplicated by another sed question. Somewhere. Exceptions to this would be sed programmers actually trying to write long scripts in it - something no one should ever do!

Questions can't be googled for

The problems faced by sed users can't really be googled for in sed's own terms. Try typing into google, "how to use sed's e command". Confusingly to the non-sed programmer, you'll see hits for the s/// command, and other hits for sed's -e command line switch, but nothing for sed's actual e command.

Askers really have no choice but to ask for the code

So, there are really only 2 possibilities:

  • The user comes to SO genuinely trying to learn sed- but as someone who knows sed, the only advice I can give that person is: don't! Don't use SO to learn sed; just read the manual.

  • Or, the user comes to SO genuinely not interested in learning sed, but as someone who just wants the code! That's, by the way, 99% of sed users, and probably 99% of people reading this, who ever used sed.

MCVEs not applicable to one-line scripts

Since a sed program is typically a one-line script, there is usually no way to break a problem down further. I don't think I have ever seen a MCVE in the sed queue before. And I am struggling to imagine what it would look like if I ever did see one.

Often hard to show your research

As noted above, it is often impossible to find these answers by Googling. As I also said, the only useful research I could recommend to anyone is to read the whole sed manual. If project timelines don't allow a 2 day window for "engineer learning sed" I think it is ethically sound for someone to not show research, and just ask the question here at SO.

What should we expect of askers then

What I expect

Not much, in the sed queue, honestly. I expect to see that they tried their best to put explain what they're trying to do, and make it as easy as possible for us to help them. But I am understanding of the fact that sed is confusing, and they often will have no idea of how to put it into words - especially if English is not their first language.

Could I expect more? I'm not sure.

What would enforcing the rules look like

At this point I'm switching into Devil's Advocate mode. What if we just enforced the rules instead? What would that look like?

As I mentioned, I think every question has been asked before. Thus, those of us inhabiting the sed queue could spend a lot of time on cleanup and other such administrative volunteer time. If ideal canonicals were found, these could be cleaned up, and it might become easier to know which questions to dupe each new question in the queue over to.

The maintainers of these queues could then sit and wait as maybe 10 questions a day came in, only to figure out how to properly dupe or close them.

But we are talking about a lot of unpaid work here, and no rep as incentive.

I answer sed questions because I enjoy it. I enjoy solving the problems; I enjoy seeing the other sed solutions; I enjoy helping people; and I enjoy learning while I do it. And, of course, I do it for rep as well.

I also enjoy cleaning up (my profile shows 186 posts edited at the time of writing), but if cleanup became the only thing I could contribute in the sed queue, then I think that would not be sufficient incentive for me to continue contributing.

In addition to this, closing questions as dupes of other questions probably wouldn't help askers, most of the time. I can't get any satisfaction from ruining someone's day. I enjoy being the one who helped some random data scientist solve their problem.

(I should add that I have no issue at all with voting-to-close as a dupe after I asked the OP if that will help them and they say yes. That's my preferred way of handling dupes.)


I argued that these send me teh codez questions deserve to be treated separately. I've noted that they're inherently different to questions about some other high level programming languages; I've noted that the expectations on both the askers and the answerers is, and must be, different; and I've proposed that this status quo should be recognised as a good thing, not a bad thing.

Now to ask a specific question

My question is:

  • Who agrees, and if there is any agreement, could we open a formal process or discussion for allowing slightly different rules in these tags?
  • 34
    I’m not sure yet if I agree 100% with you here, but I applaud the much more measured and constructive tone. Thumbs up. – yivi May 4 at 7:04
  • 3
    Ok, noted, and thank you for the feedback @yivi. – Alex Harvey May 4 at 7:37
  • 8
    I don't contribute in those 'Unix filter' tags, and this is one reason why. TBH, if poster thinks that a two days worth of work with the docs, trying stuff out etc. is too much, they should stop trying to program computers. OTOH, If they are of the opinion that 2 days is fine, but it's best if someone else did it, such deadbeats should take their requirements elsewhere. If sed etc questions are not new and useful to future SO users, why not just close them all? – Martin James May 4 at 8:50
  • 8
    @MartinJames, I think 2 days is fine, but all of us have a finite amount of time, and none of us can ever learn everything there is to learn about computers, even in a lifetime. Additionally, it's easy for me to say it'll take 2 days- that's about how long it took me, in my 40s, as a senior developer. But to your proposal, do you think just "close 'em all" is in any way realistic? I mean, for starters, who on earth is going to spend their spare time just sitting around closing sed questions? – Alex Harvey May 4 at 8:57
  • 4
    Not I, for one. I prefer to spend my time closing and deleting other stuff. – Martin James May 4 at 10:44
  • 7
    'Hey! My favourite tags deserve special rules too'.....'and mine!'........Reddit – Martin James May 4 at 10:48
  • 5
    @MartinJames, each tag already has its own rules in practice. And unfortunately in sed, AWK and others, questions get closed according to the arbitrary whims of the high rep regulars. They’re no doubt burnt out, and thus they use their dupe hammers and downvotes to intervene if a question irritates them sufficiently. Those on receiving end meanwhile assume they are being discriminated against because that’s always what it looks like, even if it’s something else. As a pragmatist, agreeing on rules that are sustainable based on the resources available would be a big step forward. – Alex Harvey May 4 at 11:13
  • 9
    @Alex Careful, this is a very constructive effort on your part but the snark is sneaking back in. It’s insulting to make sweeping statements that high rep users can’t make their own, sensible judgments about questions. You don’t know that “irritation” motivates them, just like you don’t know that their whims are “arbitrary”. Assume good faith, and most importantly keep the hyperbole down if you want to be taken seriously – Clive May 4 at 12:00
  • 4
    @Clive, just in the last 24 hours, one sed question was dupe hammered to a question that doesn’t even mention sed. Another one closed as “too broad” when the truth is the question is about using a regex to parse HTML, and that upsets a lot of people around here. It’s not snark, I’m not naming anyone, but it is what it is. – Alex Harvey May 4 at 12:17
  • 10
    And you don’t know the motivations of the people who did that, so you really shouldn’t comment on them, and especially not in the derogatory tone that unfortunately has become your signature in the last few days. This is just a general lesson in manners and crowd control mate, you can take it or leave it. But I promise you’ll get nothing accomplished like that, you may even make it worse. If you need somewhere to vent, get a blog; if you want to effect change, be smart about it. Peace :) – Clive May 4 at 12:34
  • 2
    So is the issue with sed then, or just 'the sed special rules means that if you also have another tag, there is a chance the users of that other tag treat your question just like any other SO question'? Because if it's the latter, I see that as a reason to not have special rules, since the issue arises when these special rules are met with the rest of the site :/. – Patrice May 4 at 16:53
  • 4
    Standard sed does not have an e command — which could be one reason it is hard to find. It is a GNU extension to sed, so the best place to find out what the e command is to go to the GNU sed manual (gnu.org/software/sed/manual/sed.html) like I just did to check what GNU sed does for e (it executes a shell command held in the pattern space and writes the output to the pattern space). There's no substitute for reading the manual, and knowing how to read the manual (except perhaps the rep-herders on SO; they're a sort of substitute). – Jonathan Leffler May 4 at 19:09
  • 4
    An MCVE is more than just the code. It also needs the sample data, the actual output and the expected output. The worst sed questions are those that don't explain what they want to do, don't include the sample data, don't include the desired output, and don't include very much in the way of an attempt to solve it. "One liners" are no different from other questions — they require the supporting materials. – Jonathan Leffler May 4 at 19:12
  • 7
    The difficulty on SO with duplicates is finding the right duplicate, and the SO team has consistently, for a decade, declined to provide tools to help people maintain searchable lists of duplicates so as to make it easier to link to them. Consequently, I conclude that SO has no interest in having duplicates identified quickly and easily — which is not wholly unreasonable when you realize they need eyes on the pages to sell adverts, etc, so closing questions as duplicates probably doesn't help they're bottom line. Besides, there's a lot of unpaid manpower out on the web quite willing to help. – Jonathan Leffler May 4 at 19:16
  • 3
    Good luck at changing the culture... My standard comment when someone complains about MCVE: "Switch to Bash. The folks who follow the Bash tag (and related tags like Sed and Awk) have some of the lowest standards on Stack Overflow. They are happy to do all your work for you. Just dump your requirements on them. No effort required." – jww May 5 at 20:49

..., the questions often can't be broken down further

I'm not sure which questions you're looking at, but most of the ones I've seen most certainly can be broken down further (or generalised to something that would be helpful for others).

Taking as an example (since this is what I'm familiar with)...

When you post a broken regex, you should split it up and compare it against the individual parts you want to match. That should lead you to the part that's the problem, and allow you to ask specifically about that. In the linked example, that may come down to asking how to match 2 consecutive characters or what square brackets mean.

When you post a "I need the regex" question, that's usually just too broad. A good version of that question might've involved trying a very simple regex like <img.*src= (if you can't come up with that, you're not at the point of being able to get an answer to the above question yet, but you can ask another question in the process of trying to come up with the aforementioned regex). After that doesn't work, that might've led to the revelation that you want to match the first occurrence of src, or that you want to not match a > with ., either of which would lead to a much better question that could apply to many other scenarios as well. Well, that question is trying to use Regex on HTML, which tends to be quite controversial for good reason, but the point remains.

The result for the above is really simple questions (which any given person may or may not see as an appropriate question for the site), but that's the underlying problem the authors of those questions have, so that makes sense.

it is hard if not impossible to google for the answers ... sometimes it is difficult to put into words what you're trying to do if you don't understand the language

This is always somewhat of a problem, but it's very similar to problems in other languages, where there are also plenty of cases where finding an answer to your original problem would be next to impossible while finding an answer to your sufficiently-broken-down question should be straight-forward (or you find the answer yourself in the process of breaking it down).


You didn't seem to present an argument for this, except "it is smaller", which doesn't make it inherently different.

Almost every possible question has been asked before

Great! So we can stop accepting questions for these tags, and clean up the questions we have.

We're in the business of creating a repository of high-quality questions and answers, not making sure there are actually questions for people to answer.

If you're looking for questions to answer, expand your knowledge to other topics where there's a greater need for answerers, or go to Reddit or somewhere else, which would be more in line with what you're looking for.

(Actually I don't think we'd ever truly run out of good questions for a sufficiently complex topic like regex or sed - usually there'd still be some particularly complex questions, or particularly simple ones that just hasn't been asked yet. Although the number of possible questions would tend towards zero for something static.)


No, not read a full manual, but:

  • Do a basic tutorial in the topic you're working with
  • For debugging questions, look up all elements of your code in a manual
  • Do a Google search for whatever the underlying thing you're trying to do is (which you got by breaking it down as above)

And I do not expect a reasonable proportion of askers to actually do that, but we should require it nonetheless.

I personally just expect most to go somewhere else that's more accepting of their question after we make it clear that we don't want it.

MCVEs not applicable to one-line scripts

It definitely is. Just because it's already short doesn't mean it can't (or shouldn't) be made shorter.


This is the problem with moderation as a whole.

Although there are a lot of people who do it regardless, because they care about the site.

The observant reader may notice that I didn't actually present a solution here for how to deal with these tags. These tags might be a good example of the problem, but I feel said problem is quite widespread and possibly can't be solved with the system we've built, with too many people who like these types of questions. We probably just need to take small steps to improve wherever possible, until Stack Overflow decides this is a problem and finds and implements adequate changes to the system to address it (or someone else decides to create a new system).

  • You actually have convinced me that regex & sed are slightly different. In that, I don't think there's an excuse for not wanting to learn and understand regexes whereas I think not wanting to ever learn sed is legitimate. (Although I definitely encourage everyone to give it a try all the same!). Your argument, however, seems untenable when you say this: "Great! So we can stop accepting questions for these tags, and clean up the questions we have." If sed questions aren't accepted, you lose all the sed people to close questions as dupes. – Alex Harvey May 4 at 16:09
  • 1
    Personally, I think in a topic like sed, the solution to dupes is pretty obvious: Just allow new questions, as long as they're not exact duplicates of other questions. If two answers differ even by a single, necessary sed command- and if the OP lacks the ability to figure out how to add it themselves- then it's not a dupe. Simple. – Alex Harvey May 4 at 16:14
  • 7
    @AlexHarvey I've used sed a couple of times. I don't have that much interest in learning it, beyond solving my immediate problem, but the times I did use it I followed my usual process of trying to break the issue down to the smallest possible part, sufficiently researching each of those and only asking a question if that failed. Although I never got to the last part. Doing research is core part of asking questions here, and should be a core part of the process a professional programmer (which is who Stack Overflow is for) follows to solve any problem. – Dukeling May 4 at 19:24
  • 1
    But you have only asked 6 questions in SO, ever. This is an argument, if followed to its logical conclusion, for more or less not allowing people to ask questions on SO, ever. It says that, if the answer is already in the manual, no one should ask here. Meanwhile, I would argue that if the answer is not in the manual, it probably should be! Thus, we could shut down SO, and just focus our efforts on raising PRs against the manuals and clarifying amibiguities in docs? – Alex Harvey May 5 at 8:36
  • 2
    @AlexHarvey Getting documentation changed is a lot harder than posting a question and answer on Stack Overflow. Also, documentation and Q&A's serve different purposes: in some cases it's just not viable to expand on every little part sufficiently for everyone to understand it, in other cases it's just not clear what you should be looking up (checking the docs primarily applies to debugging questions where you already have some function to look up). Most of my research involves "do a Google search", where I often find Stack Overflow questions of which I would've asked some myself had they not existed. – Dukeling May 5 at 14:54
  • 3
    @AlexHarvey "you haven't answered how SO's community of experts could continue to exist if the flow of legimitate questions tended to zero" - I do think there are too many experts for most subjects, and it would be better for the site if a decent proportion of them stop answering (whether in their tag, for the most part, or altogether). Although there'd always be some new questions for those who remain. Related: Does it feel lately like all questions have already been asked and answered and there is nothing more to do? – Dukeling May 5 at 15:02
  • 6
    "...but it's very similar to problems in other languages, where there are also plenty of cases where finding an answer to your original problem would be next to impossible while finding an answer to your sufficiently-broken-down question should be straight-forward..." Exactly. And whether we require users to do this up front is what determines whether SO is a personal help desk or a documentation resource. If we don't require it on these tags, then we won't be able to require it on other tags. And the fact we've done such a horrific job of requiring it is a major source of quality problems. – jpmc26 May 5 at 21:38
  • 8
    @AlexHarvey It's also important to realize that when askers get answers like these, they're being hurt in the long run. They're learning to depend on others to give them the answer once it's past their current ability. They'll never be able to tackle more complex problems on their own if they don't learn to break them down into trivial ones and then assemble the various pieces themselves. That's true for all programming technologies. Sometimes the best thing to do for someone is say, "I know you can do this, so I'm not doing it for you even though I know it's difficult for you." – jpmc26 May 5 at 21:47
  • 1
    @jpmc26, we can all agree that removing the requirement to do research isn't the answer. – Alex Harvey May 6 at 1:00
  • 1
    @AlexHarvey Isn't that what you're proposing for the questions in these tags? If not, and you don't require the type of research I suggested above, what sort of research do you expect from askers of these questions? – Dukeling May 6 at 8:14
  • 1
    @walen If anything, all these questions from people who can't break down their problems should be cordoned off somewhere else, since this is well outside what SO was built to be. It could be called, "SO Help Desk." – jpmc26 May 7 at 6:44
  • 1
    @jpmc26 By focusing only on content quality it seems to me you are despising several positive aspects of having a QA board. How would you explain Code review even exist, if help desking didn't belong in QA ? Why do you believe the "overall widespread problem" of quality (to quote dukeling last paragraph) is left unadressed, if not by design ? – Arthur Havlicek May 7 at 15:00
  • 2
    @ArthurHavlicek I'd be very surprised if Code Review questions even rarely pop up in Google searches (and end up being what the searchers are looking for). This is because those questions fundamentally aren't generalisable (answers might be, to some extent, but don't make the question searchable). Contrarily, most programming questions typed into Google get at least one Stack Overflow result. I'd argue there's a fundamental difference in the goal of these sites, but even if there isn't, the above shows there should be. Generalisable questions and showing up on Google means long-term value is important – Dukeling May 7 at 18:53
  • 2
    @ArthurHavlicek You can look at the help center to see the difference in purpose. Stack Overflow says "we're working together to build a library of detailed answers to every question about programming". It doesn't even mention helping people with their specific problems (at least not there). Code Review replaces the part about building a library altogether: "We're working together to improve the skills of programmers worldwide by taking working code and making it better". – Dukeling May 7 at 19:02
  • 2
    @ArthurHavlicek I should point out I think the help center is a bit too easy-going considering what the site is actually like. That being said, plenty of what is recommend in the help center (the Tour page I linked to, but also the rest of it, and especially the official close/upvote/downvote reasons) for how to improve a question certainly helps with asking a question that's helpful to someone more than you. That supports my point either way (even if we drop the "build a library" goal completely, those rules are all still there, and following them would still end up building a library) – Dukeling May 8 at 0:16

I think you are overlooking the cultural aspect.

There is, I'm sure, enough coverage on the 'Net about the ".nix" culture that I don't have to go into detail describing it here, but I want to point out that sed, along with awk, bash, et. al, are all "hacker tools from a hacker culture". Surely you are aware of this.

If not most, then certainly a large majority, of the users that watch the tag learned to use sed according the norms of that culture. Which is to say, if you want to learn how to use sed, you gather up the man pages, and fire up the terminal and bang on it until you have it figured out. That's how they learned it, and that's how they expect others to learn it. So a "give me teh codez" question about sed is met with virtually instant disapproval, based on "Lack of Effort".

And yes, regex started out the same way, as a Unix tool. But once it escaped to Perl and Tcl, it was more or less "kidnapped" by the cultures of the scripting- and higher-level language programmers. There are a lot more users that watch the tag from those other cultures, so these kinds of questions receive a warmer welcome.

This is, of course, not to say that one culture is better than another, but only to observe that they are significantly different. And ideally, all questions should be treated objectively the same way, based on the same objective criteria. But we're dealing with people, not ideals. There is no "formal process" that will change someone's cultural outlook.

And, as Hans Passant points out in comments, the tag has a very high answer rate, so there are very likely to be several cultural factors at work. The answer rate could conceivably be due to many questions in that tag being easy to answer, so they get answered by new users looking to gain reputation, who are perhaps not as steeped in "hacker" culture. I cannot imagine a "formal process" that would alter their behavior, either.

  • 7
    This cannot explain why [sed] has such an extraordinarily good answer rate. 82.5% last week, 87.4% last month, 90.8% lifetime. Very few tags at SO get close to that. Other than [regex] :) I'm not 100% sure why, but surely it has something to do with those questions being easy to answer accurately by the hacker-culture aficionados. Not having to explain anything in such answers surely helps as well. – Hans Passant May 4 at 15:02
  • 2
    Yes I agree with @HansPassant. I started out in Unix culture long ago and you are right about all that, whereas it appears to be the C, C#, C++ etc types in Meta who are more concerned about "send me teh codez" whereas those of us in the sed etc queues don't see it as a massive problem- most of the time. The tension arises because enforcing the rules is the exception rather than the rule, and it therefore has the appearance of being applied selectively and unequally. – Alex Harvey May 4 at 15:07
  • @HansPassant: I'd be curious to see data on how many of the answers are posted by relatively new (possibly younger) users. Could be a confluence between the culture of new users not quite steeped in hacker culture, but looking for easy-answerable questions. Quite likely it's even more variables than that. – Mark Benningfield May 4 at 15:27
  • @AlexHarvey: I don't follow the sed tag that closely, but if it has such a high answer rate, then I guess I don't really understand what the problem is that you're trying to solve. – Mark Benningfield May 4 at 15:29
  • 2
    @MarkBenningfield, it is the conflict that I don't like. Imagine how the OP feels from that question the other day. He's from a non-English speaking background. It was the first question he ever asked here. He's now had I think 8 downvotes and 10 close votes. What's he thinking? Imagine you're that guy. And he did nothing wrong at all. I would like us to be simply able to help people, without feeling pressured that we must downvote and close vote all the time. – Alex Harvey May 4 at 15:40
  • 11
    @AlexHarvey: You are ascribing animus and conflict to the curation process. There is none. This goes right back to the question of whether SO exists to help/mentor users, or to build a question repository. That issue is still not settled to anyone's complete satisfaction. – Mark Benningfield May 4 at 16:00
  • This is very funny: I want to point out that sed, along with awk, bash, et. al, are all "hacker tools from a hacker culture". – EGL 2-101 May 5 at 5:31
  • 2
    @EGL2-101 care to clarify what exactly you consider funny in that sentence? – Alexei Levenkov May 5 at 6:47
  • 2
    @MarkBenningfield, I think you mean the curation process is not supposed to cause conflict. It does, however. And it always will, because no one is ever going to enjoy being downvoted and/or have their questions closed- especially if they're under pressure at work and really, really need help. But I think you're right that SO can't decide if it's trying to create a Q&A database; or help people; or both. – Alex Harvey May 5 at 11:34

Some thoughts reading answers and comment :


This mindset strikes me especially as unacceptable (sorry for original poster). I've posted questions about things I could figure out by myself in a matter of hours - and the simpler, the more upvoted. MOST highly voted questions are things you could figure out in a matter of minutes outside SO, reading the docs, yet none of the highly voted answers is a link to the documentation. If everybody spent 2 days solving problems on their own before opening a question, SO would hardly exist at all.

Programmers can be busy and impatient, and by throwing a stone at them for it, 1. we are contributing at creating a hostile environment for newcomers that just want their questions to be answered 2. we miss the target of what the masses usually use the site for, to get instant quality answers to their dumbest and uneducated questions (and sometimes more when they are lucky).

Now I understand that the topic is for questions that are both simple to answer and too specific to a user to be useful to the community. But while I understand answering send me teh code questions may seem like misuse of the site, I believe they are still useful for many reasons :

  • Traffic aquisition of users that had a sed problem one day
  • Reputation of the site overall to adress problems
  • Education and mentoring of users on their way to have the solution.

Ultimately, I firmly believe in user-driven moderation : if it's open and upvoted, it probably is useful and belongs where it is.


I don't see a problem, I see a huge opportunity for people to get their question answered. Where else than in SO you would have an army of expert to ask for your most technical and obscure problems ?

  • +1 from me. While I agree with most of this, I'll address, I don't see a problem: The problem is right there, in the paragraph that preceded that one: I also believe in user-driven moderation, but while there are two irreconcilable viewpoints- let's say "ours" and "theirs"- the moderation doesn't work well. At all. Consider, I asked about why a question of mine had been closed IMO incorrectly. Since then, the post had about 10 upvotes and 9 downvotes. Whatever it is exactly, it tells me the community is deeply divided, and some are upvoting for the same reasons as others are downvoting. 1/ – Alex Harvey May 7 at 5:47
  • And I believe that all the downvoting, if not done consistently, definitely communicates most of the experienced hostility- whether the hostility is intended or not- towards the users asking the questions that, in the opinion of the downvoters, are of low quality. Which feeds directly, as you say, into the well understood problem that Stack Overflow is, by reputation, all over the world, hostile and unwelcoming. 2/ – Alex Harvey May 7 at 5:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .