MinibuildsWiki:Consensus

Template:UnderConstruction

 * Deletion policy
 * User blogs
* Chat guidelines
 * CheckUser policy
 * Theme-specific policies
* Manual of Style
* What Brickipedia is not
 * Manual of Style
* Category Guidelines

In order for something to change, Brickipedians have to work together and come to a **consensus** as to how the wiki is changed. The system that we use to form a consensus is merely applied discussion.

## Life cycle of a proposal

This is the basic structure of how proposals are processed in the community:

1. A user creates a proposal. The scope of the proposal can be on any scale — from a simple MoS addendum to a desysopping request.
2. The community starts discussing the proposal. Depending on the nature of the proposal, conflict may arise, which is resolved by calm debate.
3. After the discussion has died down, an administrator not involved with the discussion closes it, clearly identifying the consensus.

Of course, this exact process is rarely followed. Sometimes a discussion can be closed with no consensus, sometimes an involved administrator can close the discussion, and sometimes the discussion is resolved with a simple straw poll. The exact procedure strongly depends on the situation; remember to use common sense and bend this structure as much as is needed.

### !voting

!voting, pronounced "not voting" (the exclamation mark means negation in computing), is the nickname Wikipedians have given to this type of discussion. Sometimes, to make closing the discussion easier for the administrator, we prefix our messages with bolded words indicating our view on the proposal:

* **Support** - I think this would be a good idea; here's why. ~~~~
* **Neutral** - Meh, I'm not sure. ~~~~
* **Oppose** - I don't think this is a good idea; here's why. ~~~~

Although these are not required, and such prefixes are not needed for your !vote to count, they are customary in discussions. Feel free to get creative with the prefixes; a couple other standards include **strong support/oppose**, **weak support/oppose**, **question** and **answer**, **suggestion**, **WTH**, and many others.

In deletion discussions, usually the support/neutral/oppose system is replaced with **delete**, **neutral**, and **keep**. Similar adaptations may be necessary for other discussions.

There are no minimum requirements for participating in a !vote. You don't even need a user account; IPs can discuss just like registered users.

### Closing debates

If a discussion has achieved a good number of members, and activity has died down, an administrator not involved with the discussion may choose to **close** the discussion. This basically means adding a message like the following:

* **Closed** - Consensus is... ~~~~

Determining consensus is a process that requires lots of experience, which is why it is generally reserved for administrators.

If you feel that a discussion needs to be closed, but you aren't capable of closing it, you can request for closure like so:

* **Request for closure** - I think this discussion is over. ~~~~

Of course, whether the discussion should actually be closed is at the discretion of the closing administrator.

#### When to close a debate

* When discussion has died down and a consensus has been reached.
* When a sufficient number of people have !voted on the proposal, proportional to the scope of the proposal. For example, only four or so !voters are needed to close a minor move request, but RfAs should have the majority of the community involved.
* When the debate is not likely to achieve consensus or be resolved within a reasonable amount of time.

#### What to consider when determining consensus

* How strong the arguments are on both sides.
* How many users !voted for each side. Be careful that you aren't just doing a head count; closing debates should never be objective.

## Special cases

As with all policies on Brickipedia, there are many exceptions and special cases. Rules and guidelines are intended to adapt to the current situation a la UCS.

### Snowball clause

Wikipedia has a widely accepted essay known as the **snowball clause**. It basically states:

*If a proposal doesn't have a snowball's chance in hell of surviving a set of processes, then there's no need to run it through all of those processes.*
In other words, if it's obvious that a proposal will never pass, it's okay to close it even if you aren't normally allowed to do so. You can use the corresponding !voting prefix **snow oppose**.

### Closing with no consensus

Some wiki debates are unlikely to achieve consensus. They may be ideological disputes, or simply arguments that can never be resolved through reasonable means. In such cases, an administrator can close a debate and say that no consensus has been achieved; in such a situation, no change occurs and everything stays the way it is.

### Request for Adminship Consensus

RfAs (Request for Adminships) use a slightly more orderly system of discussion that looks a bit more like a vote. It looks like this:

#### Support

* **Support** - This user would be an excellent admin, and here's why. ~~~~

#### Oppose

* **Oppose** - I don't think you're ready yet, and here's why. ~~~~

#### Comments

* **Comment** - I have something to add. ~~~~

### Straw poll

It's generally unproductive to debate over colors and stylistic preferences, so such disputes are usually resolved via a simple straw poll. A straw poll looks like this:

#### Support

1. ~~~~
2. ~~~~
3. ~~~~
4. ~~~~
5. ~~~~

#### Oppose

1. ~~~~
2. ~~~~
3. ~~~~

(Note the use of numbered lists instead of bulleted ones.) The side that gets the most points determines whether the proposal passes or not.

Straw polls are considered to be an over-simplistic way of resolving disputes, so they are only used to determine a consensus when ordinary debate is terribly impractical. Aside from stylistic disgreements, straw polls are used for Brickipedian of the Month, userbox and infobox colour proposals, and Improvement Drive nominations. Most of the time, however, you should resort to discussion.

## Example discussion

This is my proposal. ~~~~

* **Support** - Here's why. ~~~~
	+ You're wrong, and here's why. ~~~~
		- Your argument is incorrect. Why? Because... ~~~~
* **Oppose** - I don't think this is a good idea. ~~~~
	+ Please explain. ~~~~
		- Here's why. ~~~~
* **Suggestion** - Instead of this, why don't we do that? ~~~~
	+ Hear, hear! I think we should do this. Here's why. ~~~~
* **Comment** - I want to point this out. ~~~~
* ~~**Neutral** - While this part is good, that part is bad. ~~~~~~
	+ Actually, that part is good. ~~~~
		- Oh yeah, you're right... ~~~~
* **Strong support** - Here's why. ~~~~
* **Question** - I don't get this. ~~~~
	+ **Answer** - Here's what it means. ~~~~
	+ **Answer** - Here's another meaning. ~~~~
* **Oppose** - I like cake. ~~~~
	+ What?!? ~~~~
* **Weak oppose** - While this part is very good, this part is pretty bad. ~~~~
	+ No it isn't. ~~~~
		- Yes it is. ~~~~
			* No it isn't. ~~~~
				+ Yes it is. ~~~~
					- No it isn't. ~~~~
						* Yes it is. ~~~~
* **WTH?** - Now *that* totally redefines "ridiculous." ~~~~
	+ Actually, it's a good idea, and here's why. ~~~~
* **Request for closure** - In general, discussion is heading in this direction. ~~~~
* **Closed** - The result is this. ~~~~