# A Modest Proposal: the [popularity-contest] tag

Over at this question, the OP doesn't want to use an objective winning criterion like code brevity, but instead wants to accept the highest-voted answer. To me, that smells like a popularity contest.

Personally, those two examples above are reason enough for me to never post a popularity contest. However, if someone should, against their better judgement, feel that such a contest has value, a [popularity-contest] tag would suffice to caution serious coders to stay away. It'd be like Parental Advisory, except in this case it's not a content-free advisory. :-)

On a similar train of thought: should popularity-contest questions be "strongly encouraged" to be community-wiki'd?

• whats the thinking behind making them community-wiki? – vzn Mar 25 '14 at 3:00
• @vzn You have to remember that I wrote this post in the very early stages of this site's life, when popularity contests were not welcome on the site (since they are non-objective). I still personally dislike them, but the community seemed to have become more accepting in the years since. – Chris Jester-Young Mar 25 '14 at 3:03

For me, the novelty of a code golf site is seeing the novel ways people apply the features of languages I am interested in. As a result of this, it is quite likely I will be upvoting answers which are interesting to me, rather than worrying about testing shorter solutions in languages in I might not be interested in (I am not only referring to GolfScript here.) An accepted answer is only worth 1.5 upvotes, so if there are a lot of users like myself on the site, such solutions will consistently underperform in terms of rep gains, even if so called popularity contest questions are made CW. There's no point penalizing anyone for answering what some might consider an unclear question. All puzzles are objective questions to a point. We either need to decide that those questions with less strict acceptance criteria are off topic or accept them for what they are.

I suggest that it would be sufficient to emphasize the importance of appropriately setting expectations for acceptance criteria in the faq, and perhaps require the use of a set of (less condescending) acceptance criteria tags eg: strict, popular-vote, or whatever-i-feel-like

The ability for the community to upvote and downvote questions is a feature of the StackExchange platform, not a bug. Let's not try making it into something it's not. There's nothing stopping anyone from making a great code golf site with automated testing/automatic assigning of points to the shortest answer. This isn't that site.

• +1 Thank you for a more nuanced approach, of coming from a "let's be upfront about what to consider an accepted answer". The tags you suggest may be helpful too; then people can filter the tags that they're uninterested in. – Chris Jester-Young Jan 31 '11 at 3:10