As opposed to technical sites, answers to code golf challenges are not supposed to be helpful to the challenge poster, so up-voting them does not serve as much of a purpose.
I think a viable path which also solves some of the needs for ensuring quality challenges would be to prevent code golf posts from receiving any answers until they reach a certain threshold of upvotes.
I like this idea of keeping questions unanswerable until sufficiently starred, as a sort of Sandbox.
I do have a concern, having seen upvotes in the CGCC Sandbox meaning "this is a cool idea" rather than "this is ready to go live", that the same would happen here. Maybe the ideal would be to have some separate vote indicating "I've checked through this Sandboxed question and found no issues or ambiguities".
Chat uses stars ☆/★ to pin messages. Reputation-gaining votes are with hearts ♡/♥.
This proposal accomplishes the following goals:
* Encourage writing challenges by rewarding challenges more than answers.
* Give experienced users more say in site policy
* Trusts experienced users more when it comes to judging the quality of a proposed challenge.
* Shows more confidence in the ability of experienced users to write good challenges.
## Voting systems
There are two voting systems in effect:
### Variable voting
Posts with variable voting use the TopAnswer system where one can choose to vote with between 1 vote and *P*(*r*) votes, were *r* is one's reputation, as follows:
### Single voting
Posts with single voting can only ever receive a single vote from each user, no matter how much reputation that user has.
It is fairly easy to ask a meta question, so Meta Questions have **single voting**.
People need to be able to express opinions on Meta Answers. Experienced users are better able to decide what is good site policy so these posts have **variable voting**
## Code Golf, Fastest Code, etc.
Challenges are very hard to get right. Experienced users are better able to judge what constitutes a good challenge, so these posts have **variable voting**.
To ensure quality challenges, all challenges are locked down (cannot receive any answers) until they reach a threshold of hearts. This threshold *T*(*r*) also depends on the authors reputation *r*:
This means that newcomers need 7 votes to launch a challenge, while more experienced users need less. xnor-level users would need 2 upvotes, and Jon Skeet only 1.
Once one has reached 9 rep, just two 100-rep users voting full marks would be enough to launch.
The "7" can increased if we see that low quality challenges are approved.
Before having gathered enough upvotes to launch, other people's challenge posts will read:
> ♡0 rate as ready: ♡♡♡
Your own will say:
> ♥0 (more required to launch)
After launch, other people's posts will say:
> ♡0 rate as good: ♡♡♡
Your own will only say:
It is (usually) relatively easy to answer challenges, so these have **single voting**.
## Golfing Tips
It is very easy to ask for help on golfing, so Tips Questions have **single voting**.
It is also easy to provide tips, so Tips Answers have **single voting** too.
## Blog Posts
Blog posts use variable voting. They cannot receive answers.
I, too, like the idea of keeping question unanswerable.
But I don't like the fact that currently answers aren't applicable for stars. I don't have ideas on challenges, but I love to try to tackle them with TeX (because programming in TeX is such a unique experience). As it currently stands someone who has asked many questions/created challenges will have more voting power to approve new questions compared to someone who has answered many but didn't create any. Though I'd personally think that the latter person can judge on good/bad questions just as good.
Turned my comment into an answer.
> I think a viable path which also solves some of the needs for ensuring quality challenges would be to prevent code golf posts from receiving any answers until they reach a certain threshold of upvotes.
@@@ answer 683