Staging Ground Workflow: Canned Comments

Please use language and links to ensure comments are immediately actionable. New users are often not familiar with the workflow of maintaining content and benefit from being explicitly told which tool/path to use.

For example, the Needs focus instructions just address the user:

Try focusing on …

who may fail to find the edit option or mistakenly use comments.

Instead, directly link to the tool and name the content to work on:

Please [edit] the question to focus on …

Add a comment for links to or images of code/errors/data/etc.

This is a very common problem. While it's generally covered by existing close reasons, it would probably help to explain more specifically, as it currently requires reading some amount of text on the linked pages to find the relevant advice.

I'd propose something like this (feel free to use or modify this wording):

Instead of posting code, error messages, data, or other text as images or links, please [edit] your post to copy/paste or type the actual text directly into the post (for code, use a code block). Text in images cannot be copied to reproduce the issue, and error messages in images cannot be searched. Links may become invalid if the linked site changes. If your code is too long to fit in the post, we have tips on how to create a minimal, reproducible example.

The proposed canned comments below are inspired by the Question Close Reasons

I would suggest you have a look at the frequently asked questions about asking, formatting and scope of the site. These come up again and again, and the faq pages are often linked from question comments.

In particular:

• This doesn't look like the actual problem you should be solving
• Tell us about resources you already found and how they didn't solve your problem
• Post the entire, exact error message
• Do not link to paintings of code or errors or tabular data
• Be clear about the problem
• Read about asking homework questions
• Avoid bad tags
• Do not link the page with your issue, post enough code to allow reproducing it
• Format your code
• Create a StackSnippet, with React
• Create an example for SQL questions
• Use proper indentation for readable code
• Use code formatting appropriately
• Do not thank or greet people
• Format your tables using markdown
• Ask only in English, it's ok not to be a native speaker
• Only you know whether your code solves your problem correctly

Here is a large collection of comments that I've put together, based on Bergi's helpful dataset and Bergi's outstanding list of links.

Unclear:

As it’s currently written, it is hard to understand your question. Please [edit] to add additional details that will help others understand what you are asking. You can find more information on how to write good questions in the help center and here.

MRE:

Please [edit] your question to include a minimal, reproducible example in the post that everyone can compile and run. We encourage you to use code formatting for code.

Didn't work:

Please [edit] your question to elaborate on what were you expecting from your code, and what actually happened. If you got an exception/error, include a minimal, reproducible example, post the line it occurred on, and the entire exception/error message you got. That will help us to understand what the problem is so we can better help you.

Attribution:

Whenever you copy from somewhere else, you must provide credit to the original source. To fix it, you can [edit] your question to include a link to the source, mention the author's name, and quote the copied content. For more details, see referencing help and this FAQ.

General tips:

Welcome to Stack Overflow. We encourage you to read our [ask] page and [edit] your question to improve it. Good questions tend to receive quicker, better answers from the community.

Background:

We ask that you research your question before asking and tell us what you've found and why it didn't meet your needs. Make your question useful for others by providing relevant background and context. This helps us help you, by clarifying your requirements and helping us avoid suggestions you've already rejected.

XY problem:

I'm wondering if this might be an instance of the XY problem. I encourage you to review your post to make sure you have stated your requirements clearly, ensure that you are not prematurely ruling out possible solutions that would solve your actual problem, and share the context and motivation for your question.

Conciseness:

On Stack Overflow, we prefer to avoid greetings, salutations, thanks, signatures, and similar remarks. Please [edit] your question to remove them. See our [help/behavior] for more details.

English:

Please [edit] your question to ensure it uses proper grammar and spelling. It might be helpful to review the tips we've collected on writing style on Stack Overflow.

Correctness/debugging:

Asking whether your code is correct is off-topic here. Our mission is to build up a knowledge base that will be useful to others in the future, in the form of high-quality questions and answers, and such yes/no questions are unlikely to be of value to future visitors. Please review our guidance on this topic and [edit] your question accordingly.

Your post states that "Approve pending minor edits" will require a comment, and that the canned comments will be available. However, none of the three presented canned comments represents a minor issue - as you say, they are inspired by the related close reasons, and thus describe major issues with posts such as not including enough debugging details.

Thus, it does not make sense to include these canned comments for the "minor issues" flow - if a user feels like any of the three presented comments is appropriate, they should have selected "Require major changes" instead. I would suggest you either simply remove the ability to use a canned comment for the "minor issues" flow, or prepare a separate set of appropriate canned comments for minor problems. Not sure what these comments would look like, however you could always start without any canned comments and then add them after release of the feature based on the most frequent manual comments.

Here are a few that I expect may be useful.

Images:

Please do not upload images of code, text, data, or errors when asking a question. This makes your question impossible to search, impossible to edit or copy-paste, and inaccessible to the visually impaired. Please [edit] your question to transcribe text, use code formatting for code, and see the formatting documentation for tips to make your text appear nicely without resorting to images.

Titles:

Please [edit] your title to make it more descriptive. A good title should be short, help readers know what to expect, and help others find your page via search.

Homework:

Questions asking for help with homework-style tasks must include a summary of the work you've done so far to solve the problem and a description of the difficulty you are having solving it. I encourage you to review our guidance on how to ask questions about homework and exercise-style tasks and [edit] your question based on the recommendations there.

Links:

Questions must be self-contained. Please don't rely only on a link to your code. Instead, please review our guidance on posting code, construct a minimal, reproducible example, include it in the question, and use code formatting for code.

Here are the canned comments that we have so far.

No need to work yourself on writing canned comments - the community has already done this for you! Many users have their own set of canned comments, sometimes adjusted to fit the particular question, sometimes just copy-and-pasted time and again.

You're sitting on this data already - here is a simple data explorer query listing the most common comments that ask to edit a post from the last years. Not all of them are useful, not all of them are up to the current code of conduct, but when sifting through the list you'll be able to identify a theme of pain points.

Hot take: canned comments about the question's subject are not as helpful as people think they are.

Canned comments about formatting, posting code as images, and altogether off-topic questions: fine. But about these comments from the OP:

1. The question doesn’t have enough detail or clarity to be answered. Please provide additional information such as examples, code, or any errors you’ve encountered to help others answer your question.

2. This question is too broad or has multiple parts and it will be difficult to get a good answer. Try focusing on one aspect you’d like answered, or split this up into multiple questions.

3. There isn’t enough information to reproduce the described issue. Update the question to include desired behavior, a specific problem or error, and the shortest code in an accessible format necessary to reproduce the problem.

Neither of those point the asker to what exactly is wrong with their question.

I'll paraphrase advice that has been posted on Meta many times before: if you don't want to tailor your comment to the question at hand, don't post a comment at all but just downvote and/or closevote.

Comment #1 is okayish, for an actual unclear question. But every generic "your question is too broad" comment is met with "no it isn't, I just want to ask how to build the next Facebook, that is one question" (#2), and every "non-min-reprex" comment (#3) is met with "but all my code is in the question".

Especially in #2: why is it "too broad"? Is the question about writing an entire application? Or are there five follow-up questions that have been asked and answered before, which won't reasonably fit in a single answer? Askers will need specific feedback about that.

And for #3: which is it? Is code missing? Is a compiler/runtime error missing? Is input/expected output missing? All of those? Or something else?

So, responding to:

We are planning on implementing canned comments in order to help cut down on the time required to review a question, while also providing useful feedback to the [a]uthor.

Canned comments will only make reviewers happy, without any culture change. You won't achieve the second goal from that quote. Canned comments do not provide specific, actionable feedback, when the problem with the question is specific.

Please carefully select which comments should be allowed to stay in their canned format, and which must be tailored to the question.

Off-Topic Help Requests

Questions from people who ask for help related to using computers, but not for getting help about writing code by themselves.

I think that we have many questions from people having some sort of problem or goal who are looking for help to solve / achieve it, but, for any reason, they are not interested in applying the solution by themselves or learn anything from the site. Usually their "requirements" are "too localized", so nobody who writes code will learn or have benefits from that question.

Sometimes the question blatantly asks for someone to write the code for them, ask "is there code that I can copy-paste", to fix code written by someone else that stopped working, or they are looking for someone to adapt code found in the wild to their specific needs.

The common close reasons for these questions are ask about general computing, ask for recommendations, or not reproducible, but it might use other the closing reasons.

IMHO, it doesn't make sense to provide feedback about how to write the question. The feedback should be about the site scope and what is on-topic or off-topic. Something like

The question doesn't look to be about writing code or using tools for this task. You still might get help from this site if you are able to make it on topic. Ref. Why is "Can someone help me?" not an actual question?. For further details about question that might be asked here see What topics can I ask about here?

Setting expectations

It's important that new users understand as soon as possible that Stack Overflow won't write code for them, produce an individualized solution, guide them through every subsequent problem they encounter with the same task, etc. While the tone of "Stack Overflow is not X" isn't generally appropriate, canned comments need to reflect that mentality, and they must be firm in doing so.

Fundamentally, certain questions can't be rescued by editing them. If a question is far too broad, a duplicate, or caused by a typo, then edits that make the question suitable for Stack Overflow... would fundamentally create a different question. It's important to keep this in mind; canned comments must not falsely suggest that an unsalvageable question could be salvaged.

About close reasons

While the reasons to comment should of course be informed by whether the question is suitable for Stack Overflow (and therefore by the standard reasons for closing questions), there is not a one-to-one mapping onto things that new users need to be told about the question. There are many conceptual ways, for example, that a question could lack focus or clarity; and some bad question-asking habits could prompt multiple closure reasons.

About "minor edits"

I touched on this in a comment. "minor" vs. "major" is the wrong distinction here. The real axis of concern is "can be fixed by others" vs. "requires OP's input". If the problems can be fixed by others, then they should be fixed by others, unless OP volunteers. It will be much faster and more streamlined that way, trust me.

However, it will be useful to explain such edits after the fact to OP via canned comments, so that they can improve their posting style and avoid the need for such edits on future questions.

Tailoring

Many things that one might say to a new user, in order to be useful, need to be adapted to refer to specific details of the question. Which is to say, I sympathize with CodeCaster's view; but canned comments still provide a highly useful framework for identifying issues with a question (and reminding oneself of the list of potential issues), and for making it easier to adhere to the Code of Conduct while frustration mounts from repeatedly saying the same things to multiple new users. It also potentially saves a lot of time - both typing, and thinking about the phrasing.

My proposals

With that in mind, here are some canned comments I propose for a mixed bag of circumstances:

Issues requiring OP's input

Feedback for edits already made

Ideally, the system for canned comments will fill the text into a comment field, but not actually submit it; this way, we can do whatever customization is necessary first. Again, the goal is not to ensure that everyone communicates in this exact, rigid way; the goal is to save time by providing a useful framework for describing problems with questions.