Show your work: one simple trick to make meta effective

Question

Every day, good-hearted people come to these sites and run into serious problems. And then you come here or to another meta site, seeking to propose a solution to the problem you've encountered... And no one cares.

• Your discussion gets ignored
• Your feature-request gets downvoted
• Your bug gets slapped with status-norepro

Sound familiar? Has this ever happened to you? Well, it shouldn't have to be this way. Chances are, people do care; they just don't understand what you're talking about. When you're super-excited to share the brilliant solution everyone needs to know about, it can be really hard to remember that you're talking to people who don't live inside your head and who need some really basic information to even begin to understand the information you're trying to convey; so you rush straight to the solution and skip everything else. Don't feel bad; I've done it too. Heck, most of my co-workers have done it; even Jeff Atwood did it once or twice. If the folks who built these sites still screw up when trying to use them, you can't feel too bad about doing it too...

...That said, you totally don't have to screw up! Meta sites can be a real effective venue for solving problems, if you just take a little bit of time and follow one little rule...

Show Your Work

Remember when you were like 5 years old, and a teacher would give you some simple math problem? What is 121/11 ? And you'd smile triumphantly, and write down 11 and hand in your paper... And it'd land back on your desk with a big red circle and the words, "show your work".

It didn't matter that you were right. The teacher wanted to know how you were right. Which meant long division (or that weird thing with boxes if you're younger than me). If you got the process wrong, having the right answer wouldn't help - you'd just get tripped up on down the road with some harder problem.

Meta works the same way, except we can't even know if you're right unless we can follow your work; otherwise you just get a few hundred people trying to guess if you're right or not - which is hard, and tends to not go in your favor. You don't want that. You want us to follow your line of reasoning all the way from "I don't like this" to "...and that's how to fix the quality problem forever", nodding our heads and smiling the whole way.

Oh yeah - for this to be effective, your work has to actually... y'know, work. For example:

• If you wanna discuss the scourge of low-quality Xcode questions, you have to actually provide at least a few examples of Xcode questions and demonstrate how they're causing problems.
• If you wanna propose additional guidance for folks asking Xcode questions as a solution to the above, you gotta demonstrate how the guidance you propose could actually be used to improve poor ones.
• If you wanna propose forcing people to comment when downvoting as a solution to unfixed questions, you have to demonstrate both the problem (downvoted questions frequently lacking comments and not being fixed) and how the solution would address it (evidence that informative comments generate fixes, evidence that mandatory comments are generally informative).

If your chain of reasoning falls apart... Or is missing critical steps... Then your post will likely be badly-received.

Oh. There's one more little thing you might want to keep in mind...

Bonus tip: Keep it short.

If it takes you a full page just to describe the problem, chances are most people aren't gonna read far enough to find the solution you're proposing... Or they'll skip your entire post and just vote based on the title. Hope you wrote a good title...

There's a trick to this too: you don't have to put everything into one post!

• Chances are, the problem has already been discussed at length before; if you did your research, you can just link to those past discussion(s) and get by with a brief summary.

• If the problem has never been discussed before, or if previous discussions have suffered from not showing their work... Then maybe you should just discuss the problem and save proposing fixes for another day. Who knows, someone else may think up an even better solution than the one you were about to propose!

Fatigue is a terrible thing, both for the folks reading your post and for you the writer; if you can remember to wrap it up when you get tired, your readers will thank you too.

And on that note...

Further reading:

• How do I participate in Meta and not die trying?

• The challenges of persuading a large, critical audience

Answer 1

Treating good questions with the appropriate attention is the best way to help people change in the way you want

Thanks for this useful guidance, I agree with everything. Except...

...what happens next? There are a zillion good questions, which follow your instructions to the letter, are highly upvoted and they are routinely "ignored". I put that in quotes because I know they are read. The fact is that they are left unanswered by you guys.

Sometimes the community can take care of itself, however on things like bugs and feature requests, we are basically waiting for the magnificent Stack Overflow posse to do something.

Now - I can understand that even highly upvoted feature requests and bugs take time to be implemented, or might never get done. What I think you could improve is to communicate what your intentions are up front instead of having this stuff disappear in a black hole.

So: yes with all you say, but can I equally ask SE staff to take care to at least acknowledge highly-upvoted, short, self-explanatory meta requests?

---

A couple of examples that happened to me in the past 2 months: 60-score feature request without answer, 40-score bug report without answer. I'm sure there are dozens of similar examples.

Answer 2

This seems to take care of the 80% use-case (shall we say), but it doesn't seem to address the more long-standing, venerable, and received discussions which...

• Don't immediately lead to a resolution (not that this is surprising; consensus amongst strangers is tough) (example),
• Aren't acknowledged as an enhancement (example), or
• Aren't communicated that this is acknowledged as a bug (example).

Unfortunately this time, these three things need to be addressed as part of this flow to make Meta feel more effective. Without the feedback loop, it doesn't matter if we tick off all of the boxes on your list; we're still kind of stuck not really knowing. This is the metaphorical equivalent of getting a blank homework paper back from my teacher; without any indication of what I did right, I don't know if I did anything right at all.

I truly believe that the above points need to be addressed, too. There should be some clear process that gives Meta-goers some clear thoughts around the consensus of their feature request, and there really should be some work done on communicating if something's a feature request or a bug - even if automated, saying "declined" after a few weeks is better than not hearing back after years.

Answer 3

It's worth remembering there are different classes of meta posts on different sites. And effectiveness may have different metrics here. With discussions, I'm looking at votes, up or down. With feature requests, the ideal is getting the feature accepted or rejected, but I have a few I know someone has looked at. Bugs need to be squished. More or less, I want attention (in the nice way) and I seem to get it.

On MSE, most of my questions are bug reports or questions about odd bits of site culture. If it involves rendering, I include a screenshot. If it doesn't, and involves a browser, I include OS (since different OSes have different fonts available, and render things differently) and browser (ditto). SE versions also have builds - and I include that when I remember (I forgot, and just found it through going through old questions for this answer).

While I have a few outstanding FRs, many of them seem to be fixed, even if team sometimes doesn't realise it, and at least at some point, someone in team has at least noticed. Odd site culture ones are less useful, but get tons of attention.

I treat policy questions as if I'm trying to convince someone in 5 minutes or I'm asking someone at an information counter and there's a queue behind me. I lay out the problem, suggest a solution and wait. In many cases, stuff gets fixed, or discussed in the comments.

On per site metas it's a slightly more multifaceted problem. Least on SU in addition to the mod team, we have a few users who post answers at least as good as, or better than anything I write - and least on MSE I try to be that guy. Some things do need higher powers but policy questions on per-site metas are easily answerable by someone who knows the site. Getting and keeping those people on meta is tricky. We did it, I suppose, but I have no idea how.

I don't particularly like the idea of deleting bugs cause they are not fixed. Feature requests, maybe but even then, an appropriate tag or an answer saying why it can't be feels better from a user perspective. Even then, seeing an edit from someone from TPTB on a question shows me it's been looked at.

Also, clever titles help.I wouldn't suggest being too clever though.

Answer 4

I'd like to contribute two prime examples of how not to get your point across; two feature requests I made that ended up being downvoted and derided, but eventually implemented!

In this one I didn't fully explain why this was important, it's too short with no evidence:

How can I show that the duplicate question answers my question?

In this one I've approached it wrong and triggered a few people by mentioning 'Gamification', when if I'd given it more thought would have come across a lot better.

Allow users to set 'target' badges

Answer 5

I'd like to try an experiment.

I do not know if I support this or object to it (I do believe I actually have a counter-intuitive case against this advice, strangely enough, but it may be a weak case, and I'd like to do this experiment first, because it is decent advice). In an effort to stick to the "show your work" advice, I have chosen a random sample of 72 various types of meta posts from across the network, and am asking anybody with some time to help rate the posts. If you are interested in participating:

1. Visit this Google sheet and choose File → Make A Copy.

2. Follow the instructions in the sheet:

   Go through some or all of the links below and fill in the "your rating" column with the following:

   • 0: Contains no attempt at supporting evidence.
   • 1: Contains at least some attempt at supporting evidence, even if poor.
   • 2: Contains a pretty decent attempt at supporting evidence.
   • 3: Contains a great amount of supporting evidence.
   • x: Does not apply (for whatever reason, try to use sparingly, this means this sample just wasn't appropriate.)

   
   Also fill in the "too long" column with one of the following:

   • n: A comfortable length.
   • y: Definitely too long.
   • s: Way too short (last minute add-on by request).
   • x: No opinion, or can't tell.

   
   Important: Try to rate objectively, that is, based on the amount of evidence provided rather than based on whether or not you personally find it convincing or [dis]agree with the topic.

   Fill in as much as you can, every bit helps.

3. When you are finished (or as finished as you want to be), post a share link (be sure to click 'share' in the top right of the sheet to make it accessible) to your copy of the doc in the comments here. If you don't intend to view all 71 posts try to pick a random sample rather than starting at the top, hopefully this will increase coverage. Try to rate at least 20.

Once sufficient data is gathered we can take a look. I am purposely not sharing the details of how these posts were sampled until after data is collected.

Yes, this may fail miserably. It may turn out to be a huge, thankless waste of time. But, I've got my fingers crossed.