Suggestions on how to get questions better accepted?

Question

Well, I've only written 2 question so far, both started in the sandbox. the first question The lost pawn problem is (I think) a very interesting question to solve. After fixing all the minor mistakes @PeterTaylor pointed out in the sandbox post, and gaining some up-votes, I posted to the main site. But the question didn't get any answers (just a few up-votes...). I thought maybe people think it's too hard, so I edited and added an un-golfed simple solution to show it's not that hard, and providing a way to generate test cases. Still... nothing. on the other hand, a much less interesting question (IMO) I posted after, gained some attention: Build Me a Pyramid. So, I'm just trying to figure out, what makes a question better accepted here? do people prefer (a bit boring and repetitive, IMO) ascii-art challenges, which as I see is the majority of the newer questions here. Or maybe it simply a matter of luck? Perhaps rephrasing the question might help gaining more attention?

Answer 1

Just hitting upon a great challenge idea isn't enough. You must consider how you word and structure the specification. In fact, I'd dare to say that the clarity of the specification is more important than the actual challenge idea!

The fundamental understanding of a specification is that it's not merely a presentation of inputs, outputs, and what-to-do, but rather the communication of that to the reader. To quote George Gopen from The Science of Scientific Writing:

It does not matter how pleased an author might be to have converted all the right data into sentences and paragraphs; it matters only whether a large majority of the reading audience accurately perceives what the author had in mind.

Read through your specification carefully. What follows are some generic things to keep in mind when writing and editing your spec. I would imagine that a lot of prolific challenge writers on PPCG consider these questions subconsciously while writing.

1. Is it clear to the large majority of the reading audience? Remember that not everyone is familiar with mathematical notation or jargon. Explain things in simple terms first, then technical terms, not the other way around. For example, with your pawn question, we would explain the notion of weighted moves in English before the function notation.

   This challenge takes place on a chess board with n squares width and height. A pawn starts on one side of the chess board, and must its their way to the other side. Some positions are more difficult to move from and to then others -- that is, a move between two particular squares has a weight, or a cost, associated with that move. More formally, we can say that there is a function f: {1,..,n-1}X{1,..,n}X{-1,0,1} => R+ of weights...

   If you must use abbreviations, define the abbreviation the first time you use it. Italicise the first instance of an unfamiliar word, and define it in the same sentence as where you italicised it. Typeset very important information in bold.

   Don't forget to check for grammar and spelling mistakes too. They also infringe on the ability for the reader to clearly understand the specification.

2. Does your specification flow in a logical manner?

   In your specification, place the most important section first (that is, the section that is most vital to the reader's understanding of the challenge). This is often a summary of the challenge, or an introduction to the subject matter of the challenge. Then place the next sections in order from most important to least. This will differ from challenge to challenge.

   Then, in each section of the specification place the most important sentence first for that section. The most important thing about the input, for example, is what data you're getting as input. So put it first:

   The input are the weights of all the moves that the pawn can make on the chess board. This is represented by a three-dimensional array where...

   Then, in each sentence of the specification place the most important clause first.

   You shouldn't follow this idea rigidly -- situations where trying to move important clauses first reduce the readability of the passage can occur. But it's a good thing to keep in mind.

3. Does your specification include needless complexity?

   Balance inclusion of details with clarity. Including too much detail in the same sentence or paragraph can result in the overall point becoming obscured.

   Also in the same category of needless complexity is word choices. Instead of writing "utilize", write "use". "Firstly" can just be "first". "Making arrangements for" could just be "arranging".

In my opinion, the user Zgarb writes the clearest challenge specs. I encourage you to read their challenges to get an idea of what a really good challenge spec looks like.

(See this question for more advice. )

Answer 2

Keep it Simple

Something I've noticed is that questions that are too complicated are less likely to do well. I'm not talking about the difficulty of the solution, I'm talking about the amount of detail and complexity involved in the question. Your lost pawn problem had a lot of moving parts. The three dimensional array, the exacting textual output specifications, et cetera.

In contrast, Build Me a Pyramid is (roughly) one step: given a number, produce a pyramid of that size. I think this helped it do better.

To address some points from your question, it's not about ascii-art. My most upvoted code-golf question is Find the Smoothest Number, which is another one-step problem. In contrast, Edge Elimination Number was one of my least upvoted code-golf questions, and it is much, much more complicated.

Check out Calvin's Hobbies

Second, there is definitely a lot of skill involved. One of the sites best question writers is Calvin's Hobbies, with 15 different questions at vote totals of 50 or more. Taking a look at their question might help you write better ones of your own. Good luck!