# A proposal to combat Meta Bloat™: The Big Consensus Freeze

I believe it's a widely acknowledged problem in this community that the number of meta posts a new user needs to know to figure out all the rules has long got out of hand. We require certain answer formats, allow a large (but not arbitrary) set of I/O methods, have certain standard loopholes, special rules for counting interpreter flags, and then a bunch of exceptions to all of these. Sure you can probably get started without knowing most of these, but you'll miss out on golfing opportunities or violate some rules here and there, and it probably takes a while of being an active user until you've got an overview over all the relevant meta posts that we've accumulated over the years.

Even the well-known list of admissible I/O methods is somewhat losing its value in my opinion, because it might take a while for people to see new suggestions and there's just so much to take in. The equally well-known post saying that all answers must be full programs or function is even misleading because there's a later consensus that allows REPL answers if they're designated as separate languages.

Anyway, I believe this is a problem which presents a huge learning curve to new users, and I have a proposal for finally dealing with it:

Let's freeze all old, clear consensuses and consolidate them into one big FAQ post for answering rules.

Here is how I imagine that will work:

• We make a list of important meta posts whose answers are usually used as references for one site rule/policy or another.
• We record the current consensus on each of these posts and write up one big post that summarises all of them in a structured manner. This becomes a new meta post. It can link to the relevant meta posts for reference (and for people who want some further reading on how that rule came to be).
• We close all the old posts as dupes of the FAQ post and optionally lock them to physically freeze the votes.

This doesn't have to mean that our policies will be set in stone forever! If people want to propose new policies or changes to old policies, they can simply make a new meta post so we can have a fresh discussion about that specific change instead of people posting answers to old questions that will never gather enough votes to catch up with the old answers. Moving away from the polling culture that shaped many of our older policies would actually enable us to have more constructive discussions about the policies and it will more easily reflect the community's current opinion.

The clear benefit is that we'll have a single destination for people to review the rules, which we can point new users to and which can be mentioned in the Help Centre. I hope that in process of compiling the rules we'll also uncover any contradictions in existing policies and might be able to streamline some of them. Moving forward we should be able to make better decisions about policy changes because it will be easier to get the big picture.

I have started to compile a list of relevant meta posts, but it's doubtless incomplete. If anyone wants to have a look I've put it up in a pastebin for now. We can discuss the actual list once we've decided that we really want to do this. In the meantime, feel free to ping me in chat with any important posts missing from the list.

For now, I'd like to use this meta post to get some feedback for the proposal. Is this a good idea? Am I overlooking an issue with this that makes it a bad idea? Does it need any modification, can it be improved?

PS: This problem isn't limited to rules for answering. But I'd like to focus on one thing at a time, and for the majority of users the answering rules are more important (and I think there are also more of them). If this works out well, we can tackle a separate FAQ post for writing challenges.

• Is your intention then that when a "new" consensus is reached on a new topic, that that question is also closed/locked/duped of the FAQ and the FAQ itself updated? I would imagine "Yes" otherwise we're just having this conversation again in a couple years, but how long is long enough before a consensus emerges? Mar 29 '17 at 19:55
• Thanks starting this discussion! I think that calling the rules "consensuses" is one of the most misleading things at SE. They are not consensuses, they are majority votes. And they don't even represent the majority of the users, but the majority of people who happened to be active when the meta question was posted. It seems impossible to decide which contradicting rules are effective, so having a single place for them and a clear system for changing them would be a great improvement! Mar 29 '17 at 19:55
• @AdmBorkBork I guess so, yes. I'd say we know it when we see it. When the discussion and voting dies down, we can amend the FAQ post. If discussion and voting dies down and no clear consensus emerges, that would indicate that more discussion is needed. I don't think I'd set hard and fast rules on the exact process of proposing changes. We can probably decide that on a case-by-case basis. But if you have a suggestion, I'd love to see it in an answer here. Mar 29 '17 at 19:57
• I've kept pretty up-to-date regarding consensus and policy, since I'm on a lot, but the amount of time it can take me to find the relevant post to refer a new user to shows how necessary this is. Thanks. Mar 29 '17 at 21:29
• Wait, so does that mean that if I reposted "Answers don't have to be written in a programming language", it might actually be accepted instead of ignored? Mar 29 '17 at 21:37
• @NathanMerrill Actually, that makes two posts that resulted in the consensus that non-programming languages are allowed (there is another one in my pastebin). That's exactly the problem. There's apparently a decent amount of support for allowing non-programming languages, but very few people are aware of it, whereas the "What's a programming language?" post is very popular, so people enforce the rules that programming languages are required. I suppose once we start collating everything for the FAQ post, we'll find more such inconsistencies and settle them more definitively. Mar 29 '17 at 21:39
• (E.g. based on these posts I'd say that's a clear "yes, non-programming languages are allowed", but that doesn't mean that "everything goes", because on the other hand we have posts that clearly show that we want solutions to consist of some form of code that can be executed by an existing program. Dominoes come to mind.) Mar 29 '17 at 21:41
• @MartinEnder I think that problem is easily solved because we measure things by bytes. If its not measurable in bytes, its not valid. Mar 29 '17 at 21:44
• @NathanMerrill Not everything is code golf. :) But yes that's a probably a good rule of thumb. Mar 29 '17 at 21:45
• @NathanMerrill: You actually won that argument, in the end. The loophole post's at +22/-16, i.e. not enough to apply, and is just likely to go down further over time.
– user62131
Mar 29 '17 at 22:44
• – user62131
Mar 29 '17 at 22:45
• @MartinEnder Didn't you say before that CSS is only a programming language under specific conditions? relating to this. Also, the definition of what programming or non-programming languages are allowed should probably be cleared up. For example, we basically decided that dominoes IRL wouldn't be allowed, because that's a non-deterministic implementation. Apr 3 '17 at 14:46
• @mbomb007 Are you replying to any specific comment? I think that's basically what I said in my comments to Nathan. Apr 3 '17 at 14:52
• Nope. I didn't read the comment chain. Apr 3 '17 at 14:58
• I'm of the opinion that any challenge writer should include links to relevant consensuses in their challenge, this of course doesn't account for this like Flag counting, but Quine challenges should have a link to our standard quine definition, and most should have links to our Standard IO and Loopholes. Apr 6 '17 at 23:36

I propose that each commonly-used language have a separate explanation of the rules that most pertain to it, with code examples. I think this is more digestible that a big general FAQ, especially to new users.

(Meta post to try to make this happen.)

Different languages consider different rules important. For example, allowing curried functions is central to Haskell, but almost never comes up in, say, Python. If the FAQ misses this rule, that's a big omission for a Haskell golfer reading it. If it includes rules like this, it becomes bloated, and a golfer must search through lots of rules irrelevant to them. A language-specific explanation avoids this.

I would also find it friendlier if the rules were explained for the language rather than just listed. Code snippets showing allowed and disallowed methods make the rules obvious, saving users the need to interpret statements written to be language-agnostic. The rule "Programs may output to STDOUT" would have meant nothing to me as a brand-new Python golfer, but "you may print the output" would be perfectly clear.

When writing my first golf in PPCG, I first looked for a bunch of Python answers to see their general I/O structure, and based mine off of those. I would have been much happier to have the main I/O structures listed in one place: def/return, lambda, input/print. A list of rules would be far beyond me -- I just wanted something I could use to write a submission. A quick-start guide for beginners would have been ideal.

I recognize that writing a guide for many languages is a lot of work, but I think it's the best way to help and retain new users. I'll write an example guide for Python that I hope will get across the type of thing I'm imagining.

• Yes, please. Honestly, I wouldn't even mind having language-specific rules. In fact, we're desperately in need of them for some cases: our truthy/falsy definition is well and good for languages with a canonical conditional statement, but for esolangs where that's not the case, people have just been making up their own definitions. I'd still argue that we need one central jumping off FAQ post, because a lot of things will be common to many languages. But from there we can link to posts for specific languages, where separate guides exists, that address the language-specific details. Mar 29 '17 at 22:07
• And yes, this is a lot of effort, but I'm absolutely willing to help out there as well, and I'm sure some other active users would jump in for their languages of choice, too. Mar 29 '17 at 22:07
• I would certainly keep a very keen eye on C# (and possibly Java, got to keep your enemies close). This solves the third of my concerns, and I agree this could work well in addition to a general FAQ, providing qualifications and unique rules. My only concern (other than initial effort requirements) would be long-term maintainability: if a consensus changes which affects a large number of languages then it will be costly and error prone to implement it. Mar 29 '17 at 22:10
• @VisualMelon At least we'll know where we need to make the changes, if we have a directory of language-specific posts in the main FAQ. Mar 29 '17 at 22:13
• I think language specific rules for IO is a good idea. We'd have the default rules, and posts could override them for a language or set of languages. I'd be really hesitant to have specific rules outside of IO though Mar 29 '17 at 22:58
• @NathanMerrill Yes, I think this will mostly apply to valid types to represent things, and answer formats (program, named/unnamed function, REPL). Mar 30 '17 at 8:28
• @MartinEnder, I don't see how language-specific rules would prevent people from making up their own definitions. In fact, I fear it would make that problem worse: it creates an opportunity to slip in a convenient definition which might manage to pass unnoticed. Mar 30 '17 at 14:08
• @PeterTaylor So what do we do? Exclude languages where the standard truthy/falsy definition doesn't apply from challenges requiring truthy/falsy output? Mar 30 '17 at 14:10
• @MartinEnder, the cleanest solution is probably to have a small collection of general-purpose truthy/falsy pairs (e.g. 0/1, true/false, 0/non-zero integer, and empty vs non-empty string) for languages which don't have inherently truthy and falsy values. Mar 30 '17 at 14:15
• @PeterTaylor I think my point is that some languages have inherently truthy/falsy values without having conditionals. (E.g. in regex-based or other pattern matching languages, it's obvious to choose whatever the language uses for "match"/"doesn't match".) But maybe let's continue that discussion elsewhere instead of flooding xnor's inbox. ;) Mar 30 '17 at 14:19

# Include a list of definitions

I've been feeling like a standardized set of definitions would be greatly helpful.

This would be helpful to new users, as we've got a lot of terms we like to use, such as "objective" or "competitive", and even some basic stuff like "input/output" or "programming language" that have PPCG-specific meaning.

It'd also be good for old users, as many terms get thrown around interchangeably. I'd love it if we could standardize terms so that, for example, "Submission" means the actual code and "Answer" refers to the entire post.

Obviously, the controversial terms (such as programming language) would need to be linked to the appropriate post, and could be changed if the meta consensus changed.

• Has been done before Mar 30 '17 at 0:57
• @VisualMelon The problem with that post is that it doesn't explain basic terms, and it has a lot of overlap with the (upcoming) "big consensus post". For example, the "Write a function" and "input/output" have a lot of stuff in them that are basically rules in definition form. Mar 30 '17 at 1:27
• I agree, it's not fantastic; figured there should be a link to it though Mar 30 '17 at 1:32

Moving away from the polling culture that shaped many of our older policies would actually enable us to have more constructive discussions about the policies and it will more easily reflect the community's current opinion.

How are we going to move away from a polling culture? It seems to me that we're stuck with it because (with the odd exception) SE doesn't exercise dictatorial power; and mods are not elected to form a policy-making body. The SE model is a community taking decisions by direct democracy*.

In fact, one advantage that polling has over discussion is that it gives everyone a voice, whereas a discussion with thirty people will have at least thirty viewpoints and without heavy steering won't reach any conclusions.

The big problem I see isn't polling per se but the way the technical limitations of SE shape that polling. Meta is susceptible to FGITW perhaps almost as much as main, which works against constructive discussions. My impression is that it's quite frequent on meta that someone who wants to push a policy will ask a question and self-answer almost immediately because they've already spent time thinking about it; the dissenting answer may not arrive for a day or two because it takes time to put a finger on the flaw or to find the right words to express it, and in that time the sole answer can potentially pick up a lot of votes from people who didn't see the flaw. To get truly constructive discussions and decision-making we really need a way of having the discussion before anyone is allowed to cast a vote, but I don't see that happening any time soon.

* There is a minor weighting towards higher rep users in the sense that if everyone with e.g. close vote privileges decides to implement one policy then it will be the effective policy regardless of the lower rep users holding a majority of overall users in favour of a different policy. But in practice I don't think I've seen any issue split along those kind of lines.

• I was mostly referring to the practice of the question author posting all possible viewpoints as answers right away and letting people vote on them, instead of giving dissenting opinions the chance to make a case for themselves. That makes the FGITW even worse, because the question author likely has a bias anyway that will show through the question and/or answers, so someone who disagrees not only has to make a good argument, they also have to undo the damage that may have been done by a poorly argued original presentation of that position. Mar 31 '17 at 12:09
• I agree that FGITW has a huge effect on meta. However, I think in many other cases, the problem isn't just the FGITW, but also that the question itself is written by a person who is leaning one way or another. There's a reason debates are ran by a (hopefully) impartial moderator. Apr 3 '17 at 15:53

I'm in favour of tidying everything. I know I'm too lazy to keep up to date with the FAQs that don't apply to C# in particular (means I'm possibly uninformed about the validity of answers in other languages), and they are something of an invisible hurdle for new users.

I would like for us to discuss, and clearly define how we will deal with:

• Enforcing any consensus (generally I think we do a good job of this already, but some written policy would be nice, otherwise new users and people like me who disappear for months at a time aren't sure how they should tackle these things: do we downvote invalid answers? if so, not from new users?)

• Changing consensuses, and old/new answers which violate them (should we define the validity of answers according to when the question was posted? if so, we'd need a transparent history... etc.)

• (Multi-)language specific concerns: the tendency in the past is to provide general guidelines, but this (slim) concensus (which has no saturation in the wild; people actively promote the opposite and I can't blame them) suggests we may need more granularity for some issues, or accept that keeping things simple trumps niche (if real) concerns, and this should be very apparent (i.e. do provide language specific commentary, if not ruling, for 'areas of contention')

It would be nice to see some sort of provisional timetable for when and how all this might happen. I can imagine it will take a while, and there will no doubt be heightened confusion during the transition period if there is one.

• Enforcing policies is covered in detail here. Mar 29 '17 at 20:44
• @MartinEnder glorious! I seem to have upvoted something there, but I had absolutely no recollection of it what so ever... Still though, that is mostly talking about the question spec, not the site-wide rules (or do we treat those as 'defaults' on questions?) Mar 29 '17 at 20:49

# Please ensure that this is featured

I feel, like this will ensure maximum visibility, especially to new users, this will allow it to sit right under the sandbox in the "featured on meta" area.

• I'm hesitant to perma-feature more posts, because they take up slots of the regular (current) hot meta posts. Mar 30 '17 at 10:04
• @MartinEnder so, would adding another perma-feature only allow one "hot" meta question to appear, or would it just make the box longer? Mar 30 '17 at 16:21
• It won't make the box longer. But the exact number of hot meta questions that still appear would depend on how many current blog posts and feature posts on Meta.SE there at the moment (which take priority). I think there at most 5 slots or so. Mar 30 '17 at 16:23
• I've suggested a possible compromise to allow this to be almost featured. Apr 5 '17 at 21:06
• @trichoplax thank you, I'm a big fan of it Apr 5 '17 at 21:14

A couple of questions:

What is the scope of this meta post? It obviously includes rules on what makes a valid answer, but does it include:

• Failed rules? If somebody had an idea, proposed it, and it got downvoted, do we include it?

• Guidelines on what makes a good submission? For example, should it include that you probably also give the un-golfed submission and explain what it is doing?

I'd vote Y/N/Y (respectively), but I'd like to hear what other people think.

• Yes, I'd agree with Y/N/Y. Since the result will be an FAQ meta question, it can contain multiple answers. So we could have an answer for the basics of writing a challenge, an answer for the hard and fast rules about solution formats and an answer for quality guidelines. Mar 29 '17 at 22:04
• I'd argue that all those things should be in separate posts to the main list of rules. Whether it's a separate question or a separate answer is less important, though.
– user62131
Mar 29 '17 at 23:05

I'd like to see this happen. I'd suggest a fairly narrow scope, though: specifically, let's have one FAQ post that lists all the rules that state whether or not an answer is legal. (If we want to write posts about other things, such as editing or the like, we can put those in separate posts; legality of answers is a large enough subject as it is.)

In terms of changing consensus, I think that we should freeze current consensus in the FAQ post, and allow posts to be made to suggest changes. If a feature quest gets popular enough, a moderator would edit it into the FAQ post of rules.

Note that to work, this is going to have to list all the rules, which means doing things like retiring the standard loopholes post in favour of this one. (Note that many of the loopholes nowadays don't really need to exist as their own rule, as they're already covered by other rules; for example, "inventing a language to solve a problem" is covered by the rule that "answers are noncompeting unless the language is older than the question".)

• You mention a "narrow" scope, but I'm not sure how its any narrower than what Martin is describing. Care to expound? Mar 30 '17 at 0:07
• @NathanMerrill: For example, "don't edit someone else's post to golf off bytes" is a pretty long-standing PPCG-specific rule, but I don't think it would have a place in the answer rules post, because it's not something that lets you determine whether an answer is legal.
– user62131
Mar 30 '17 at 0:28
• @ais523 yes the intention is definitely to focus on answering rules, not on policies regarding edits, comments or challenges. Mar 30 '17 at 7:35