text:
Editing Wikitext/Indents and Lists

In common with word processors, Wikitext allows the use of paragraph indents and various kinds of bullet and numbered lists. The few examples below show how it is done.

Indents are broadly similar to the idea of tabs on a word processor, though they can be used only at the start of a line.

Numbered lists find use in formal listings such as legal documents, and in specifications and other texts where  paragraph reference numbers might be quoted. Bullets are much used in lists of hyperlinks, and in many summaries.

An introduction to HTML lists has been included, since this method alone allows the use of the alphabet and Roman numbers for list labels.

Indentation
Indentation means increasing a paragraph's left margin. In wikitext this TAB character is the colon. When a colon is added before the start of a paragraph, the whole paragraph will be moved in by one TAB stop. To move the paragraph further, simply add more colons. Here is the text to indent three short paragraphs:

and the result of doing so is:

Note that indents are often used in combination with other symbols such as bullets; when they used in this way the indents should be written first, then the bullets.

Lists
The table of contents found on each page is handled automatically by the software and is not accessible using the list syntax. This subject refers to user-made lists within the text.

Lists are useful for short comments and summaries and are easy to make.

Numbered Lists
To make an automatically numbered list of the first order, just add a hash symbol, sometimes called an octothorp or number sign, before each line of the list. It looks like this:

The result is this:

To add a second order of numbering to the list, give the sub-items two hash symbols. The sub-item will then indent itself beneath the level one list item that resides above it. Additional levels of listing are made by adding more hash symbols. Here is an example:

The result of this wikitext coding is:

Bullet Lists
Bullet lists are used more often than numbered lists, perhaps because they are less formal. The bullet lists make blue square bullets against each item in the list. It is done by adding an asterisk before each list item. Additional levels of listing are made by adding more asterisks. Using the same theme as above, consider the following text:

The result of this text listing is:

Since lists are made up of paragraphs, it is a simple matter to add colons for indentation before the list code to shift each list item further across the page. Colons need added to each list item for this effect.

Definition Lists
Definition lists are usefully formatted for their purpose. They have a bold heading, followed by a normal text section on the lines that follow. Their name is self explanatory, for these lists are ideal for defining terms. They can be made in both HTML and Wikitext but only the simpler wikitext version is explained here. Note that the method needs only the semi-colon and the full-colon for its effect. The following text entry shows how to make list items:

The result of this text listing is:

Note that wrapped lines are also indented.

Other Ordered Lists
Alpha and Roman lists need HTML formats. These other list types are easily made in HTML, as well as the more usual numbered lists. In addition, their starting points can be preset.

The rules for making these alternative lists are as follows:
 * Ordered lists are enclosed in the tags  .
 * Each list item must start with the tag  .
 * The list format is set as follows in the leading   tag with the type attribute. See the drop-box for examples.
 * Numbering is set with type=1; the number one.
 * Lower case alphabet is set with type=a
 * Upper case alphabet is set with type=A
 * Lower case Roman numbers are set with type=i
 * Upper case Roman numbers are set with type=I; the capital letter.
 * The start value is also set in the leading   tag, with the start attribute. See the drop-box for examples.
 * Numbered lists use the intended start integer as a value. If omitted, the default is always equivalent to the first character of the intended set, as decided by type.
 * Alpha lists use the alphabet position value; e.g. start=3 for 'c'.
 * Zero and negative start values have no meaning except for numbered lists.
 * Arbitrary list labels can be set in any   tag with the value attribute. The label must belong to the selected type.  For example, if type is for an alphabetic list, an arbitrary Roman number would be inappropriate.
 * Values are numbers representing the position in the type set; e.g. 3 for 'c' .
 * The start attribute should be omitted for this method; avoids confusion.
 * List items without values will follow-on from the previous label.

In the event that list-making adversely affects follow-on text, ensure that there is a blank line or a break tag between the two. Examples of HTML list formats can be found in the examples below.

Consider the following example. The sample code uses type=a to choose lower case alpha listing and the entry start=2 sets the starting point as the second letter of the alphabet; the letter b. When the code runs it looks like this:

HTML List Examples
With type = 1, (the number one), and start = 432 we obtain:   This is the first item for numbers starting with '432'.  This is the second item.  This is the last.

With type = a and start = 2 we obtain:  This is the first item for lower case alpha starting with 'b'.  This is the second item.  This is the last.

With type = A, and either start = 1 or not providing a value for start, we obtain:   This is the first item of upper case starting with A.  This is the second item.  This is the last.

With type = i and start = 3 we obtain:  This is the first lower case roman item starting with iii.  This is the second item.
 This is the last.

With type = I, (the capital letter eye), and start = 2

 This is the first uppercase roman item starting with II.
 This is the second item.
 This is the last.

With type = 1, (the number one), and start = -29

 This is the first number starting with -29.
 This is the second item.
 This is the last.

With type = 1, (the number one), and start = -1

 This is the first number starting with -1.
 This is the second item.
 This is the last.

Proper reversed lists will become a part of HTML5. See Reversed Lists.

The various listing options are easily changed, and an alternative method for simple numbering of lines can be found in Numbered Prose. Although bullet lists can be made in HTML by setting the list items in

  tags instead of

  tags, the rendering is likely to afford only the default bullet type instead of the three types that are theoretically possible. For a complete description of HTML lists refer to the external page Lists in HTML.

title: Editing Wikitext/Indents and Lists


text:
User talk:Qrc

DIVs to make new lines? You're a man after of my own heart (assuming you're a man of course; otherwise, you're a woman after my own heart ;). --Spiderworm 16:36, 12 July 2005 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: User talk:Qrc


text:
Editing Wikitext/Pictures

Introduction
Pictures, or images, are common on wiki pages. You can add them to your pages, and this series is intended to explain how it is done.

Image layouts are numerous. Most images in Wiki are positioned at the left or right margins and the text is allowed to wrap around them. Others are positioned in a line across the page. Some are intended for the top of a page, along with a table of contents. Galleries can contain many images, and in a wide range of formats, and drop controls can contain any or all of these.

Whether the writer is new to image placement or experienced in their use, he will find something in these pages that is useful. Select from the links below, according to your area of interest.

 * To position images in a basic way then read /The Quick Course/.
 * To provide a lineup of tiled images across the page or to overlap them, then be sure to read /Tiled Images/.
 * For more complex image placement read /Images in Containers/.  This page deals with image placement in tables, galleries, and drop controls, and touches on the best use of top-section white space.

Writers within a wiki are encouraged to make use of templates in their work, and several useful templates are mentioned throughout the text.

Links

 * /The Quick Course/
 * Get an image onto the page.

 * /Tiled Images/
 * Size and position in-line images.

 * /Images in Containers/
 * Place images in tables, galleries and drop-down boxes.

title: Editing Wikitext/Pictures


text:
User:Cactuar12~enwikibooks

I'm the same cactuar12 from Wikipedia.

title: User:Cactuar12~enwikibooks


text:
Poker/Personality

There are typically four different types of poker player:

 * Loose-Passive
 * Loose-Aggressive
 * Tight-Passive
 * Tight-Aggressive

Loose means that a player's requirements to put money into the pot are lower than average. For example, a loose player may like to play hands like K3s (suited) preflop in Holdem, and could be seeing anything from 30 to 100% of flops in that game type.

Tight is the opposite. A tight player plays fewer hands per hour than his opponents average. This can result in only seeing anywhere from 10% to 25% of flops in Holdem.

Passive players are those that rarely bet. They are happy to call and fold, but they are not often seen making raises of their own.

Aggressive players on the other hand, are those that raise and reraise significantly more than the average. They may be perfectly willing to reraise you whilst on a flush draw, or whilst holding second pair.

Obviously the degrees of aggressiveness or tightness vary from player to player, but the vast majority will fit quite neatly into these classifications. Coupled with issues like how weak or strong a player your opponent is, you will have a powerful tool to help you decide what your opponent is holding in each situation. Classifying other players is also an extremely important aspect when considering your strategy for a specific table, tournament or hand.

In-Depth Strategies
There are many different types of poker players. The two broadest categories are those of successful and unsuccessful players. A player who is successful does not just look at what is in his hand and on the board. Players who are unable to read other players or do not make it a point to watch even when they are not in a hand are often unsuccessful as Poker players. Under the category of successful players, a successful player is able to group someone into one of many different categories. The first category is:

Aggressive:  Aggressive players will play almost any starting hand. The cards in their hand may be 2 7 of hearts and clubs and they will play it. They are the players who will contribute to some of your biggest wins and biggest losses because they are very hard to bluff out of a hand. If you are at a rock garden (table where everyone appears afraid of what others have) and one player is betting big every hand or every other hand and winning about every hand it is suggestible that if you have mid-pair you call their bluff at least once, to gain an accurate characterization of their betting patterns and because it is likely you have them beat. If someone is betting it up every hand and constantly winning and mucking it is suggestible to "look them up" if you think you might have it. These are the players that you don't want to try to bluff, because as bluffers themselves they will often turn the tables on you or look you up.

Passive Aggressive:   Passive-Aggressive players are often the most experienced of all players, are able to get a good read on who is a rock and who is aggressive and will not throw their chips away. Passive Aggressive players often call the blind to the flop if their hand seems decent enough (middle cards or high) and will do their fair share of bluffing, but not as much as a player who is purely aggressive. These are the players who will go after you hard and smash into the aggressive players when they get a hand. Often times Passive-Aggressive players will be the big-stack at the table because they rarely call large bets into hands they don't have a good chance of winning and rarely make mistakes. The worst enemy of a Passive-Aggressive player is a "River Rat".

River Rat: A River-Rat is often considered the worst poker player at the table. A river rat will usually bet before the flop if they have good cards and upon seeing a flop they don't like they will call ANY bet you throw at them just hoping desperately for that miracle at the end of the river. It is a common misconception among weak poker players that you will have a tougher time making money off of these types of players, when in fact quite the contrary is true. Profit in poker comes when your opponents make mistakes, and River Rats are constantly calling bets when they do not have the odds in their favor.

Rocks: A rock is an extraordinarily tight, patient and reserved player at the table. When they do not get a premium hand pre-flop they won't even call the blinds. When you are involved in a hand with these characters you can almost tell immediately that they have either got two high cards, an ace and a high or middle card, or a pocket pair 8 or higher. These players rarely play hands but when they do they will bet big. Their worst enemy is an aggressive player who might scare them out of a hand. While they will normally go far they won't go as far as most passive-aggressive players or very good aggressive players. River Rats give them a very large chunk of their change because they don't realize that when a rock is betting they have little chance of winning. The worst enemy of these players is themselves. They lose a lot of money to blinds for hands that they don't play.

Passive-Rocks: Passive Rocks are the players who will bet very very rarely. These guys will get a premium hand and will call bets with it, with an almost certain chance to win the hand will only call and will not bet. Passive Rocks are the most dangerous when they are involved in a hand with an aggressive player or a player who misreads them. Thinking that they are "chasing" cards because they are calling rather than betting, someone may bet an all-in on them and they will call, putting a bad hurt on whoever it is that raises them all in. Passive-Rocks generally do worse than pure rocks.

Slow-Players: These are some of the craftiest players. Slow-Players have unlimited restraint on betting on a good hand in order to allow somebody to think they have the best hand. These players know how to read others and know exactly how to look and bet like they have a bad hand or are chasing. Slow-Players are good at drawing as much money out of a hand as they can, especially when involved with aggressive players. These players are the worst enemy of any aggressive player because of the toughness of getting a read on them. A slow-player may catch three of a kind aces on the flop and check, just to draw another player into betting so that they can either A.) Raise them, B.) continue their play, acting as if they have a weak hand and meekly calling or C.) if they have plenty of chips and want to mislead other players as to how they play they will fold this hand and show the table then saying something like "I KNOW you have the straight" simply to make other players think that they are rocks or easy to get out of a hand and therefore making it easier for them to bluff.

The Perfect Player This player can read you by your actions, they know exactly what kind of hands you play by observing you when they are and are not in hands with you and other players and he knows how you chat or how you bet, etc. when you have a hand, including whether you are notorious for slow-playing or not. This guy will not give any money to rocks because they know if they are in a hand they almost certainly have an advantage over their hand and know when an aggressive player is bluffing and when they truly have a hand. He has elements of a slow-player, playing certain hands to draw money from someone who he knows will fold to a bet, has elements of a passive-aggressive player, betting big when its all river rats and aggressive players sitting around him, and a rock in the sense that he doesn't play bad hands in bad positions or with a "family table" meaning close to everyone at the table is in the hand. This player has elements of every class in them. These are the players you should fear. It is hard to predict the betting pattern of these players because it is modified depending on who they are in a hand with. The best way to learn how they play is to watch every single hand they are in and see how they act for each and every person, including yourself, because it will be modified when they are playing against you. You may even want to call some of their small bets just to learn what type of hand he will bet certain ways against you with so that he does not have a chance to muck his hand and leave you in the dark about them.

title: Poker/Personality


text:
Poker/Bluffing

Bluffing is a seriously overrated concept in poker. Yes, it is important, and yes every good player is a good bluffer. But it is not the be-all and end-all of the game. Certain types of players will make frequent bluffs - perhaps every 4 or 5 hands they play. This is a high variance way of playing, and only the truly great players are significant winners in this manner.

The mathematics of bluffing dictate this. For example, let's say that the pot is currently $10. I have nothing at all, and you have a moderate hand, a top pair ace kicker. I bet $5 as a total bluff. Whether this is profitable or not depends on the chance that you will fold.

I am betting $5 to win $10. I must therefore succeed one time from three to make this a positive expectation move (see expected value). If you fold 30% of the time, it is a losing move from me. If I bet $10 into the $10 pot, you must fold 50% of the time - folding 45% of the time loses me money in the long run.

Optimal bluffing frequency
The reason for bluffing can be explained using a branch of mathematics called game theory, which also gives an insight into the optimal frequency for bluffing (though it's usually only possible to work out the math in simplified situations).

Suppose you are playing 5-card draw poker against a single opponent. There is $10 in the pot from antes, and after the draw you have the opportunity to bet another $10 (no raises or other bet sizes are possible, to keep this simple). Your opponent gets:

for a made straight, while your hand is:

Your opponent stands pat, so you know he has at least a flush or straight to beat your two pair. You have four cards in the deck that can help you, so you are roughly a 11 to 1 shot to improve to a full house and beat your opponent's straight. Ignoring the possibility of your opponent betting or either of you raising, you have two options: bet only if you make your hand, or bet whether you make your hand or not. Your opponent also has two choices: call or check and fold. The expected payoffs are as follows:

If you bluff and your opponent calls, you will win $20 some of the time but lose $10 the majority of the time, so you end up with a negative expectation (the wost outcome here). If you bluff and your opponent folds you win $10 every time, giving you the best outcome here. Not bluffing gives a much lower expectation, but on the other hand it can't be negative, since you'll never put money into the pot with a hand that risks losing.

The trouble is, if we assume that your opponent is smart and knows the way you play, he can always choose the option that makes your expectation the worst: if you bluff he'll call you, but if you don't bluff he'll check or fold. If you assume that your opponent reads you correctly, then the best you can expect to make from this is 83 cents. Other than playing stupider opponents, there's no way around this.

But hold on: you can actually do better than this, if you notice that you have more than just the two options mentioned above (always bluff or never bluff). Suppose you bluff with probability $$1 \over 20$$. If your opponent always folds to a bet, then you make more than if you hadn't bluffed:

$$ \text{Expected gain} = 10 \times {1 \over 12} + 10 \times {1 \over 20} \times {11 \over 12} \approx $1.29 $$

If your opponent calls all your bets, then you still do better:

$$ \text{Expected gain} = 20 \times {1 \over 12} - 10 \times {1 \over 20} \times {11 \over 12} \approx $1.21 $$

Your opponent will choose to call rather than fold to your bets, since this minimizes your gain (and his loss), but notice that this is a much better outcome than the 83 cents you would average if you never bluffed. To optimize your expectation, you want to choose your bluffing probability so that your opponent's loss is the same whichever of the two options he chooses. It doesn't matter how well your opponent knows you or how well he has read your hand, he can't worsen your expected gain by his choice of action.

The semi-bluff
Semi-bluffing is a less well understood but vital concept. A semi-bluff is when you bet a draw to the hand that will win the pot, but you do not have anything yet. For example, suppose you are playing hold 'em with:

The turn comes:

You are very unlikely to have the best hand as it stands. You have four cards to a flush, with around a 20% chance to hit your flush on the next card. If the pot is very small (say against a single opponent) you may not be getting sufficient odds to make a call profitable. However, if you judge that the other player has a 20% chance of believing you have a pair of aces to his pair of kings and folding, the combined expected gain of either making your opponent fold, or making your hand if he doesn't, may make the bet profitable.

To simplify the math, we will assume that if you hit your flush you will win the pot without any further betting, and if you miss your flush but your opponent stays in you will check and fold on the river. We will also simplify the probability of hitting your flush to $$1 \over 5$$, and assume that your opponent will not raise your bet.

$$ \begin{align} \text{expected gain} & = (\text{size of pot}) \times P(\text{opponent folds}) \\ & \qquad + (\text{size of pot}) \times P(\text{opponent calls and you make your flush}) \\ & \qquad - (\text{size of bet}) \times P(\text{opponent calls and you miss your flush}) \\ & = (\text{size of pot}) \times \left [ P(\text{opponent folds}) + P(\text{opponent calls}) \times {1 \over 5} \right ] \\ & \qquad - (\text{size of bet}) \times P(\text{opponent calls}) \times {4 \over 5} \\ & = (\text{size of pot}) \times \left [ p + (1 - p) \times {1 \over 5} \right ] - (\text{size of bet}) \times (1 - p) \times {4 \over 5} \end{align} $$

If $$p$$ is the probability that your opponent folds given the hand and community cards he's faced with, then $$(1 - p)$$ is the probability that he will call, since we've assumed he will not raise. Observe that the value of this is dependent on the value of $$p$$, which you obviously don't know since you can't see your opponent's hand. However, if you estimate that $$p$$ is high enough, then the value above will become positive and the semi-bluff will become a profitable play.

For another example, I am again betting $5 into a $10 pot. You again have top pair with an ace kicker, and I have the nuts (best) flush draw. Here however, I do not need you to fold 33% of the time. Even assuming you fold should I hit my flush (rather than pay me more money - implied odds), I now only need you to fold around 25% of the time for my move to be +ve, and thus profitable in the long run.

Bluffing most often now happens in two distinct ways — the BIG bluff, and the small bluff. A continuation bet where you have missed the flop completely is a small bluff.

Aggressive players will semi bluff a lot more than they make straight out bluffs. The fact that once you hit you may still get more money from your opponent is a large part of this, and makes the semi bluff a powerful move in any player's arsenal.

Poker Bluffing Resources

Wikipedia.org Definition For Bluffing

Short Poker Bluffing Tutorial

title: Poker/Bluffing


text:
French/Grammar/Tenses/Near future

Futur Proche in French

Usage of Near Future
This tense is used to speak about something happening in the very near future, as an alternative to either the future anterior (le futur antérieur) or the simple future (le futur simple).

Formation of the Near Future
This tense uses a combination of the verb to go (aller) in its present indicative form appropriate to the subject followed by the infinitive of the verb that will be done.

 * Je vais faire du shopping.  I will go shopping, I am going shopping. (I am going to do the shopping.)

 * Nous allons jouer au foot.  We will play football.

title: French/Grammar/Tenses/Near future


text:
Scouting/BSA/Camping Merit Badge

Requirement 1
Do the following:

 * A. Explain to your counselor the most likely hazards you may encounter while participating in camping activities and what you should do to anticipate, help prevent, mitigate, and respond to these hazards

 * B. Show that you know first aid for and how to prevent injuries or illnesses that could occur while camping, including hypothermia, frostbite, heat reactions, dehydration, altitude sickness, insect stings, tick bites, snakebite, blisters, and hyperventilation.

First-Aid Preparedness The information covered by the Tenderfoot, Second Class, and First Class Scout first-aid requirements can help you deal with injuries or illnesses that may arise while you are camping. The current edition of the Boy Scout Handbook includes descriptions of the symptoms and treatment of hypothermia, heatstroke heat exhaustion, frostbite, dehydration, sunburn insect stings, tick bites, snakebite, and blisters. Review those pages to refresh your awareness and ability to help prevent these situations from occurring. Know the symptoms and be ready to make an appropriate response if you encounter them in a fellow hiker or someone else you meet along the way.

Altitude Sickness Camping may take you to high places where altitude sickness (also known as AMS, or Acute Mountain Sickness) can be a concern. Fortunately, altitude sickness is seldom a problem for people at elevations of less than 8,000 feet above sea level. Going to a place that is higher than you are accustomed may leave you short of breath because the atmosphere around you becomes thinner and contains less oxygen. Within a few days, your body will acclimate to higher altitudes by producing extra red blood cells to carry more oxygen to your tissues and organs, and you should feel fine. Taking steps to help prevent altitude sickness is far better than suffering from it during a hike. The following suggestions can make your "high" adventure more comfortable and more fun, too. -Drink plenty of fluids. As a rule, take in enough water so that your urine remains clear rather than dark yellow. -Ascend gradually. Permit your body to acclimate gradually as you go higher. Spend a few days at 5,000 to 7,000 feet and then a few more at 8,000 to 10,000 feet. -"Climb high, sleep low." Use this standard practice of mountaineers. While adjusting to thinner air, after hiking upward during the day, descend to a lower camp for a good night's rest. - It is also more difficult to boil the higher you go so if you don't need to go up higher, cook low it saves gas. WARNING SIGNS Watch for any of all of these symptoms of altitude sickness: - Headache - Nausea - Unusual tiredness - Loss of motivation - Dizziness These symptoms can also be warning signs of hypothermia, a far more common first-aid emergency among hikers. Begin treatment for hypothermia by making sure that the person is warm, is wearing dry clothing, is sheltered from the wind and chilly or wet weather, and has had enough to eat and drink. If the person does not rapidly improve and the elevation is above 8,000 feet, treat for altitude sickness as well. TREATMENT FOR ALTITUDE SICKNESS Descend, descend, descend! Going down a few thousand feet in elevation will almost always relieve the symptoms of altitude sickness. Rest, fluids, and food may also help. If symptoms persist or worsen, seek medical assistance.

Requirement 2
Learn the Leave No Trace principles 1) Plan ahead 2) Travel and camp on durable surfaces 3) Dispose of waste properly 4) Leave what you find for other people 5) Minimize campfire impacts 6) Respect wildlife 7) Be considerate to other visitors

Outdoor Code and explain what they mean. Write a personal plan for implementing these principles on your next outing.

Requirement 3
Make a written plan for an overnight trek and show how to get to your camping spot using a topographical map and compass OR a topographical map and a GPS receiver. If no GPS receiver unit is available, explain how to use one to get to your camping spot.

Requirement 4
Do the following:

 * A. Make a duty roster showing how your patrol is organized for an actual overnight campout. List assignments for each member.

 * B. Help a Scout patrol or a Webelos Scout unit in your area prepare for an actual campout, including creating the duty roster, menu planning, equipment needs, general planning, and setting up camp.

Requirement 5
Do the following:

 * A. Prepare a list of clothing you would need for overnight campouts in both warm and cold weather. Explain the term "layering."

 * B. Discuss footwear for different kinds of weather and how the right footwear is important for protecting your feet.

 * C. Explain the proper care and storage of camping equipment (clothing, footwear, bedding).

 * D. List the outdoor essentials necessary for any campout, and explain why each item is needed.

 * E. Present yourself to your Scoutmaster with your pack for inspection. Be correctly clothed and equipped for an overnight campout.

Requirement 6
Do the following:

 * A. Describe the features of four types of tents, when and where they could be used, and how to care for tents. Working with another Scout, pitch a tent.

 * B. Discuss the importance of camp sanitation and tell why water treatment is essential. Then demonstrate two ways to treat water.

 * C. Describe the factors to be considered in deciding where to pitch your tent.

 * D. Tell the difference between internal- and external-frame packs. Discuss the advantages and disadvantages of each.

 * E. Discuss the types of sleeping bags and what kind would be suitable for different conditions. Explain the proper care of your sleeping bag and how to keep it dry. Make a comfortable ground bed.

Requirement 7
Prepare for an overnight campout with your patrol by doing the following:

 * A. Make a checklist of personal and patrol gear that will be needed.

 * B. Pack your own gear and your share of the patrol equipment and food for proper carrying. Show that your pack is right for quickly getting what is needed first, and that it has been assembled properly for comfort, weight, balance, size, and neatness.

Requirement 8
Do the following:
 * A. Explain the safety procedures for:
 * 1. Using a propane or butane/propane stove
 * 2. Using a liquid fuel stove
 * 3. Proper storage of extra fuel

 * B. Discuss the advantages and disadvantages of different types of lightweight cooking stoves.

 * C. Prepare a camp menu. Explain how the menu would differ from a menu for a backpacking or float trip. Give recipes and make a food list for your patrol. Plan two breakfasts, three lunches, and two suppers. Discuss how to protect your food against bad weather, animals, and contamination.

 * D. Cook at least one breakfast, one lunch, and one dinner for your patrol from the meals you have planned for requirement 8c. At least one of those meals must be a trail meal requiring the use of a lightweight stove.

Requirement 9
Show experience in camping by doing the following:

 * A. Camp a total of at least 20 days and 20 nights.* Sleep each night under the sky or in a tent you have pitched. The 20 days and 20 nights must be at a designated Scouting activity or event. You may use a week of long-term camp toward this requirement. If the camp provides a tent that has already been pitched, you need not pitch your own tent. *All campouts since becoming a Boy Scout or Varsity Scout may count toward this requirement.

 * B. On any of these camping experiences, you must do TWO of the following, only with proper preparation and under qualified supervision:
 * 1. Hike up a mountain, gaining at least 1,000 vertical feet.
 * 2. Backpack, snowshoe, or cross-country ski for at least 4 miles.
 * 3. Take a bike trip of at least 15 miles or at least four hours.
 * 4. Take a non-motorized trip on the water of at least four hours or 5 miles.
 * 5. Plan and carry out an overnight snow camping experience.
 * 6. Rappel down a rappel route of 30 feet or more.

 * C. Perform a conservation project approved by the landowner or land managing agency.

Requirement 10
Discuss how the things you did to earn this badge have taught you about personal health and safety, survival, public health, conservation, and good citizenship. In your discussion, tell how Scout spirit and the Scout Oath and Law apply to camping and outdoor ethics.

title: Scouting/BSA/Camping Merit Badge


text:
User:Aya/Wikibooks/A critique of Wikibooks

A critique of Wikibooks

This is a document I am building up during the time I spend on Wikibooks. It mostly consists of a collection of current problems with the Wikibooks system, some solutions to these problems, and some provisional policies to help implement these solutions. Many of the problems and solutions listed here are ones which I have read from other users on the hundreds of talk pages on Wikibooks, and some are ones I have personally discovered. I have not distinguished between the two, since they are still problems for everyone, regardless of who identified them.

This will almost certainly remain a work-in-progress for the foreseeable future, and consequently may be internally inconsistent. I don't mind if other users make minor edits to correct obvious typos, but more substantial changes and other comments are more welcome on the talk page.

Abstract
Wiki is an ephemeral community in the sense that many of its users don't remain active for very long. There are a hardcore of long-term residents, but they are comparatively few in numbers. Basically, at any one time, there is an active community, but the members of it change quickly over time. Any procedures must bear this in mind, especially in the sense that it can take a long time to get any meaningful feedback from another user, so some users are being held back by the occasional desolation of pages such as Staff lounge. Consequently, I think standards need to be more pro-active, rather than discussional (i.e. the procedure would favour the writers own passion for the subject).

Many of the pages here remind me of the hilarious scene from Life of Brian, where the inactive 'activists' known as the People's Front of Judea suddenly learn that one of their number is to be crucified, and are informed to come quickly to help, by which their leader passionately declares, "This calls for immediate discussion!". We need to define certain common issues which occur (e.g. VfD), and come up with better criteria, to minimize the amount of discussion required. All the time wasted on discussion is perhaps time that could have been spent writing good educational content. I think it's mostly due to users being too scared to be bold.

The goal of Wikibooks
First of all, I should define the goal of Wikibooks. The first definition I can find is the first meaningful revision of the Main page made on 10th July 2003. It states:

 * The Wikimedia Free Textbook Project intends to cooperatively write textbooks of various fields and topics.

The same page currently (almost exactly two years later) states:

 * Welcome to Wikibooks, a collection of open-content textbooks that anyone can edit.

Pretty much the same meaning, so that much seems clear. Moving on to About, we are told:

 * Wikibooks is a collection of free textbooks with supporting book-based texts, that is being written collaboratively on this website.

Note that the word 'textbooks' is linked to the Wikipedia entry for that word, so we can only assume that this entry is an adequate definition for the types of content permitted on this site. The Wikipedia page appears to begin with a brief dictionary-length definition:

 * Textbooks are defined as "a manual of instruction, a standard book in any branch of study". They are further defined by both the age of the person who is to study the text and the classification of the subject matter itself. Textbooks are published by speciality printers to serve every request for an understanding of every subject that can be taught. It is a big business that requires mass volume sales to make the publications profitable. Although most textbooks are only published in printed format with hard covers, some can now be viewed online.

To be fair, the NPOV policy means it's fair to look at other dictionary definitions:

 * A book used in schools or colleges for the formal study of a subject.
 * A volume, as of some classical author, on which a teacher lectures or comments; hence, any manual of instruction; a schoolbook.

There seems to be a common connection with the academic establishments, so it would seem that anything commonly used there ought to be appropriate. e.g.:

 * Generalized books about a traditional academic discipline, such as:
 * Languages (English, French, etc.)
 * Mathematics
 * Sciences (Physics, Chemistry, Biology, etc.)
 * etc.
 * More specific books, but still commonly used by students:
 * Dictionaries/encyclopedias specific to a single discipline (e.g. a dictionary of medical terms).
 * In-depth guides, often crossing into multiple disciplines (e.g. electronics is also generally covered in physics and computer science courses)
 * Biographies of famous people in a particular discipline (e.g. Shakespeare), perhaps with annotated texts. These are commonly used in disciplines such as history, and literature, but generalized to include any famous person in a particular discipline.

More generally, the following types of content seem to be allowed:

 * Guides to computer games (lots of these, not traditionally used in any academic subjects)
 * Recipe book (arguably a 'textbook' in a 'home economics' or 'cooking' course)

I consider these to be perfectly valid. Perhaps 'students' should be extended with 'enthusiasts'. Who else is going to be reading these books? My own opinion is that any book you'd find in the 'non-fiction' section of a library (i.e. those which have a dewey decimal classification) ought to be allowed.

These are commonly denied:

 * 'Fiction' - Basically, any book you'd expect to find in the 'fiction' section of your local library, as opposed to the 'non-fiction' section. There is currently no official Wikimedia wiki for this sort of content.

Thinking about it, since Wikibooks is currently host to Wikiversity and Wikijunior projects, then anything in that scope ought to be okay, providing it is clearly marked as such. It's possible Wikijunior may allow educational fiction? Are these books allowed?

 * An_Unexpected_Visitor - Not listed on Votes for deletion
 * Ardvark_the_Aardvark - Listed on Votes for deletion

These are always denied, because they belong on a sister project:

 * Ephemeral (news) articles. These belong on Wikinews.
 * A book of quotations. These belong on Wikiquote
 * A book about the taxonomic classification of species. This belongs on Wikispecies.
 * A generalized encyclopedia. This belongs on Wikipedia.
 * A generalized dictionary. This belongs on Wiktionary.
 * Previously published works by another author, with no intention of annotating the text. These belong on Wikisource.

Common problems
The idea is to gradually convert this section into some simple procedures which serve to eliminate them.

Unreliable administrative system
Note: This section should not be interpreted as a perjorative statement about actual Wikibooks administrators, but rather a statement about the 'system' in which they act. The actual administrators tend to do their jobs well, but there just aren't enough of them. See also Badly defined scope for acceptable content and NPOV (Neutral Point Of View).

There has always been an issue that some users will create non-NPOV material or other meaningless nonsense in the main namespace. Due to the current open nature of the Wikibooks project, there is no way to prevent this. Only an administrator can delete these pages, and in order for them to do so without getting into trouble, the pages must go through a voting process (i.e. Votes for deletion), with the exception of obvious vandalism and newbie experiments. Consequently, the administrative system only really works where there are a sufficient number of users participating in these votes, and enough active administrators to get things sorted out in a reasonable amount of time.

Until this is sorted out, it's most practical to pretend there are no administrators, and to find solutions which any user is capable of implementing. There are murmurings on Meta to address this too. Looking at the latest beta of MediaWiki, if seems as if a new voting system is being worked on as well, although this may be for a different purpose.

Also, there has always been the general feeling that a user's pages (e.g. User:Aya and User talk:Aya), and any subpages thereof do not have to be NPOV, and that the user may maintain a strict editorial control of those pages. For example if I were to add the comment "Some users believe this user to be a complete ass" to a user's personal page, it couldn't really be argued to be non-NPOV, but changes of this nature are generally reverted.

 * Solutions

The obvious solution would be to allow this non-NPOV material providing it's housed in the originating user's own pages, and in fact many users already do this, to start work on a community project, before it is ready to be transferred to the main namespace, and continued by the community.

This is the paradigm I have tried to propagate, and in the process, I have separated these projects on the Main page into "Community Projects" and "Personal Projects". As to whether or not these personal pages deserve to be linked from the main page is another issue, but if they are ultimately intended to become community projects, I don't see this as a problem, since it helps the material to become more NPOV, by allowing other users to comment on it.

Newbies
Newbies experimenting with the system, unaware of the damage they are causing.

 * Solutions

The current Sandbox solution really only allows them to experiment with editing a single page. This is by no means the entire scope of the wiki-experience. They may still accidentally create loads of pages that just need to be cleaned up later. Perhaps they want to experiment with the "move page" feature on an important page. Perhaps they've been directed here from another site, and have no idea what it's all about. Get them off the site, and onto a safe sandbox site ASAP. Arguably there should be a link in the 'navigation' panel just for newbies. Try to direct them to another Wiki system to play around in like a beta version. In fact, they are the ideal candidates to thoroughly test the error-cases for the MediaWiki software, so getting them to help beta-test the next version would be a bonus.

 * Suggested sandbox wiki: http://test.leuksman.com/index.php/Main_Page
 * Controlled by m:User:Brion VIBBER (allegedly)

If that site can be guaranteed to remain up 24/7, that's exactly what we need. If we can get the DNS name sandbox.wikimedia.org to point to the same IP address, and co-ordinate with the developers to ensure that this site always contains the latest bleeding-edge release of MediaWiki, we can get some free beta-testers, while minimizing site damage. We also need to make sure all WikiMedia sites include this link. This could prove more difficult, since there are hundreds of them.

Vandals
Vandals, intent on deliberately sabotaging the site.

 * Solutions

User blocks and IP blocks help, but we could never stop a determined vandal without seriously compromising the ease of use of the site for the genuine contributor. The only real solution seems to be for other users to keep their eyes open, and regularly check out the 'Recent changes' list. Perhaps a formalisation of this process would help.

Unnoticed vandalism / newbie experiments
If a page is not obviously covered with nonsense, but content has been removed, or changed to be incorrect, no one may spot it, and the offending changes will not be reverted. A future editor may not spot it either, and make their additions. The more edits which then subsequently occur, the more awkward it will be to reverse the damage.

This can be quite irritating. You can't just revert back to the version prior to the damage, since you would be accused of vandalising the page yourself by removing the content of subsequent edits.

 * Solutions

Two possibilities come to mind, one changing software, the other wetware (i.e. the brain):

 * We could implement a system allowing you to reverse-apply the context-diffs from the offending edit or range of edits, with a single click, where possible, in the same way that CVS automatically merges in changes made by other users, while you are editing a document (this would also be neat). The offending edits will remain in the history, but a new revision will be added which appears as if you removed the offending edits by hand. This will not be possible in all cases, but would work with many common offenses such as linkspamming and blanking of sections.

 * We could make the user more responsible for the complete document they submit, rather than just the edits they've made. So, if you want to edit a page, you must first revert any vandalism before you add anything new. If you don't, you'll be considered a vandal yourself, and might get your account/IP blocked. Do people feel this is too harsh?

Policy visibility
A potential author, wanting to 'play by the rules', but can't/won't look to see what the rules are.

 * Solutions

The rules/standards/policies/whatever pages need to be much more visible. Not currently sure as to the best implementation for this. The page Help:Editing is quite visible, since it's linked to from every edit page. Perhaps this should contain a warning that the user should check out the site policies before continuing, if they wish to avoid the possibility that their edits will be reverted or deleted by another user.

Badly defined scope for acceptable content
e.g. 'no original research' from WB:WIN.

Obviously a user would be wasting their time, as well as the admin's time, to add something which is only going to be subsequently deleted.

 * Solutions

Can people please forget about the phrase 'no original research', and mentally revert it to the original 'no primary research' (less vague), or even something even less vague. See also: User talk:Aya/Wikibooks/A critique of Wikibooks. I'll wait to see if KelvSYC wants to sort it out before I change anything.

'Primary research' refers to the sorts of theses published by graduate students to propose a genuinely new theory. It would be used, perhaps, to refer to, say, Newton's Laws of Universal Gravitation, at any point prior to it being commonly accepted in Physics. These theses often involve coining new words and word-phrases which are not commonly used elsewhere, in order to refer to the new concepts they describe. There's nothing wrong with this, per se, but if everyone did it, then the language use could easily become too confusing to be of any practical benefit. (q.v. Neo). This is the primary reason that these things should not be allowed. Surely, devising a strategy for a mission in, say, GTA:SA, is 'original research' and 'primary research' in the sense that you have devised it yourself. The important distinction is that it is done using commonplace terms (within its own scope), and is focused on a very popular computer game (the bestselling of all time IIRC), rather that some wacky new theory that someone like Eddie Izzard might come up with, say, that bees are actually made of jam.

Personally I don't have a problem with this stuff either, and arguably it has sneaked in to a lot of other documents already. In fact, I'd go as far to say that I interpret almost everything I read as 'primary research', unless it clearly fits in with 'common sense', which I will define as the sorts of things commonly taught in schools. So Physics is almost certainly not 'primary research', whereas the mission walkthroughs section of Grand Theft Auto: San Andreas almost certainly is.

Maybe the policy should be phrased "this site should only contain factual infomation", with the standard dictionary definition of 'factual', then allow memetic evolution to allow the users to decide what that actually is. Arguably this appears to be the common goal of all Wikimedia projects. The policy would allow any user to correct/revert/delete anything which has been agreed to not be 'factual'. I've tried to avoid using the term 'fictional', since this has different connotations than simply being the antithesis of 'factual'.

NPOV (Neutral Point Of View)
See: Neutral point of view See also the much more comprehensive w:Wikipedia:Neutral point of view.

Would it be sufficient to link the former to the latter?

Arguably, just a special case of the previous problem. Based on some lengthy discussions from other users in the past, and my own interpretation, I think this requires a better definition.

 * What is a 'neutral point of view' anyway?

To think from a neutral point of view, to me, almost requires you to imagine you are an alien visitor from another planet, trying to make an objective analysis of the human race, and their beliefs and customs.

 * Bias

Take the more biased point of view:

 * Microsoft Windows is the best operating system.

If you see that in a Wikibooks module, and do not agree, just remember you should really interpret that as:

 * The user who wrote this believes that Microsoft Windows is the best operating system.

So you could replace it with:

 * At least one person believes that Microsoft Windows is the best operating system.

But since it's likely that any opinion is shared between at least a few people, you could also word it with the more vague:

 * Some people believe that Microsoft Windows is the best operating system.

If you're vaguely aware of the statistics, you could even replace it with one of:

 * Most people believe that Microsoft Windows is the best operating system.
 * Most people don't believe that Microsoft Windows is the best operating system.

And if you happen to know the exact statistic (I just made this statistic up):

 * 63% of people believe that Microsoft Windows is the best operating system.

Note that now, you are primarily talking about people, not an operating system.

 * True by definition

What about this:

 * A human being is a mammal.

Again, you could apply the same logic as the previous example, but it would seem a bit ridiculous to do so. You'd probably end up with:

 * More than 99% of people believe that a human being is a mammal.

The difference here is that this statement is 'true by definition'. That is that the word-phrase 'human being' is defined in most dictionaries to include it within the bounds for the definition of the word 'mammal', at least as long as the species retains its mamma. This is not the case for the MS Windows example, at least not in any dictionaries I've ever read.

 * Ambiguous statements

Back to the MS Windows example:

 * Microsoft Windows is the best operating system.

In addition to bias, it also suffers from ambiguity. How is the word 'best' defined within this context? To keep it vaguely factual, I'd probably intepret that as:

 * Microsoft Windows is the most popular operating system.

That is to say used by the most people. This is a common definition of 'best' within a similar context, but others might interpret it as:

 * Microsoft Windows is the most stable and user-friendly operating system.

At which point it becomes slightly more contentious. Probably best to avoid the word 'best' anyway. :-)

 * But, 'I believe'

What if the user had instead written:

 * I believe that Microsoft Windows is the best operating system.

Well. It's hardly a neutral point of view, but arguably, shouldn't be deleted, but (as before) replaced with:

 * Some people believe that Microsoft Windows is the best operating system.

Thus making it neutral.

Indecisive deletion policy
It's actually a good idea to bring suspect pages into 'Staff lounge', rather than just adding them to VfD. If something is contentious enough to warrant a VfD, then perhaps it needs to be discussed first to ensure everyone interprets it in the same way. Consequently many VfD's end up forever in voting while the users try to see if they are 'on the same wavelength'.

Staff lounge
It's akin to a talk page, but it has far too broad a scope for what is acceptable there. Consequently, the page invariably becomes massive, there are no standards for when the archive the page, and it ends up being too overwhelming for new users.

 * Solutions

A set of pages in the same vein, only more akin to the popular web-forum convention of subdividing different topics into different pages. Provisional subdivisions (incomplete):

 * General forum - A place for all questions which don't neatly fit into any other category. Questions could be moved at a later date, but this may be offputting to
 * Wiki markup forum - For questions relating to wiki markup, and the correct use of HTML on a wiki.
 * Votes for deletion - This is in effect a talk pages already. Adding it to a list of these forum-like talk pages could only serve to make it more visible.
 * Votes for undeletion - Ditto

Stub books
It's important to distinguish more objectively the differences between books, modules, and pages. It seems that many are interpreting a 'book' to mean the same as 'an article on Wikipedia'. I guess they're similar, but modules should be reserved for things beyond the scope of Wikipedia (although this is also poorly defined - perhaps it should be "anything more than 32k of text on as many subpages as you like").

Bookshelves out-of-date
See: All bookshelves, etc.

These should be updated to link to the main page of all new books. These indices are already inaccurate, and need an overhaul. Create more taxonomical and normative categories to remove duplicated entries. Make it obvious which pages represent the main page of a distinct book.

The definitive book listing ought to be one where everyone can agree where books go. For this reason, I suggest using the Dewey Decimal Classification, since it was created entirely for this purpose, and is extremely comprehensive.

Someone has already made a start with:

 * Template:Dewey 000
 * Template:Dewey 100
 * Template:Dewey 200
 * Template:Dewey 300
 * Template:Dewey 400
 * Template:Dewey 500
 * Template:Dewey 600
 * Template:Dewey 700
 * Template:Dewey 800
 * Template:Dewey 900

The dewey index page at page site http://isbndb.com/ could be useful.

 * Problems

The dewey system is not quite standard across the world. It is apparently the most internationally recognised, but at least the section pertainting to religion varies depending on the most popular (government-imposed?) religion in that country. The DDC was written by a US citizen, so most of the religion section is devoted solely to Christianity (too much of it in my view), whilst a very small subsection is provided for alternate religions and ideologies. In countries where Christianity is not the primary religion, the vast majority of this section is devoted to the primary religion, and the smaller subsection is used for Christianity and other religions.

Another problem is with evolution. The DDC is not designed to evolve well. The generalities section (circa dewey 000) generally houses books pertaining to computers. I have also seen these classified in the physics and maths section in some libraries (circa dewey 500). As computers become more important in our day-to-day lives, these books will become increasingly common and popular.

The existent bookshelf alternative may prove to be be more successful in the long term. Its top-level categories are almost identical to those of the DDC system already. Furthermore, it is better able to evolve than the DDC. Perhaps DDC is not such a great idea after all.

Main page out-of-date
See: Talk:Main Page

Browse out-of-date
Also it contains many red links, which is generally a bad thing.

Stub pages
I'm not sure why people have a problem with this. It seems reasonable to me that a user may take several days to try to get all their content into a meaningful place, so these should be permitted to exist for at least a certain amount of time.

Skeletons
A skeleton is a Wikibook which consists of a contents page linked to many other non-existent pages. The user who creates them will often be overwhelmed by the size of the scope they have created for themself to fill in, and often abandon the project. Newbies also have a tendency to click on these links, and type in any old nonsense.

 * Solutions

Need a good policy on starting new books. By having a stricter policy, the endless debates in VfD can be minimised. The important thing is that the policy should try to leave the book in a reasonable state at all times, since almost every book is abandoned by its authors before it can be considered complete. See: New book policy

Scope overlap with other wikis
Scope overlap with Wikipedia, and forking from Wikipedia.

 * Solutions

Make a more tight definition as to the distinction between Wikipedia and Wikibooks. It's obvious that there's going to be crossover, so for subject X:

 * If you can't be bothered to put in the effort to create a good book about X:
 * If there is a Wikipedia article about X, add it to that
 * If not, create a new Wikipedia article about X
 * If you can be bothered to put in the effort to create a good book:
 * If there is a Wikipedia article already about X, make sure your book contains at least the information present there
 * Note heavily on the Wikipedia article that a book now exists on the subject, and all new information should be put there

I shall define a good book to mean one which has more content than is generally acceptable for a Wikipedia article (probably around 32k of text).

Where an extensive and popular Wikipedia article already exists with the same name, I see nothing wrong with forking the content from there, providing it is noted heavily in the Wikipedia article

Double redirects
Are they really a problem? Need to check this out.

Orphaned pages
Including orphaned redirect pages. These are mostly redundant, and are just taking up unneccesary space. Should be speedily deleted.

Inconsistent use of capitalization
Wiki page names are case-sensitive, so one user can create a book "A history of computers", and another could create a book "A History of Computers", and they may never notice they're both writing the same book. Are title caps preferable? Needs to be standardized, or maybe they shouldn't be case sensitive? The problem below is similar.

Inconsistent use of naming
Similar to the above, what about the two book names "Computing History" and "A History of Computing", or the endless conceivable permutations which are logically the same concept. Wikipedia simply uses redirects. Is this appropriate for Wikibooks too? Would these all be listed of the bookshelves?

Inconsistent use of talk pages
Mostly they talk about the page they belong to, but there are the odd cases such as pages like Staff lounge which is a talk page in its own right. Also check out the way they've been used in Christianity/John 1, and similar pages.

 * Solutions

I believe the logical distinction between a page and its associated talk page is that the page should serve as the information, and the talk page should serve as the reasoning why the information is the way it is. In a way, this reasoning is vital for preventing an edit war of the information page. For works-in-progress, you often see this reasoning in the information page itself. This practise should not be discouraged.

For pages like Staff lounge where the informational page is effectively being used as a talk page, perhaps the actual talk page could be used to keep presentable infomation on the ways things are done within that page (i.e. the two pages are conceptually swapped over), although I supposed it could also be used as a meta-talk page. It just seems a bit silly to talk about talking on a different page, when it could all be said on the main page.

As for Christianity/John 1 etc., this practise ought to be frowned upon. It has already appeared in VfD. This is a special case which needs to be tightened up in the annotated texts policy. In my opinion, the main page should not be allowed to exist alone, since it is clearly raw text from the Bible. The talk pages should perhaps be appended to the main page, then cleared, since Wikipedians currently have no place to comment on the content of the page.

Archiving talk pages
Talk pages, and other pages which serve a similar function have a tendency to get long, and contain discussions which are no longer being monitored by anybody.

The 32k page limit
What browsers actually have a problem with this? If it really is a problem, it should be addressed in policy.

Provisional policies and guidelines
This is an attempt to standardize, in the style of nomic, what is currently popular convention, in the hopes of converting Wikibooks in something more akin to direct democracy rather than anarchy. Another analogy would be perhaps the U.S. Constitution, and its Amendments, although this is representative democracy not direct democracy. The goal is to prevent edit wars, amongst other things.

Outline

 * Use of terminology

What's a good word for documents of this nature? "Policy" seems to be the wiki standard, as well as "guideline" for more trivial things. It may be worth promoting all guidelines to policies anyway. If people interpret "policy" as "I must do this", and "guideline" as "I might do this", then guidelines would clearly be more effective if they were labelled "policies". The psychological interpretation of language is a key point. Perhaps the word "procedure" is better, since it infers activity, rather than politics.

 * Main page

 * Policies and guidelines - This page should contain no actual policies, but instead serve as a useful index to all other policy documents. The definitive index should always be the templated categories. This page will also contain guidelines.

 * Policy documents

 * Core policies - This will contain meta-policies, which are those to serve to indicate how policies are created/modified/removed, but can also be used for policies which don't require a whole document on the subject.

 * Editing policy - As it is.

etc.

 * Alternatives

Maybe the problem is simply that by breaking up the policies into separate documents, users are too lazy to read them, since each page can take a long time to load. Based on the overheads of HTML and HTTP, it is certainly true to say a single larger document will be quicker to load than several smaller ones. Perhaps a single page is better, although each section may have to be extremely terse to make it digestable.

Since there seems to be a lot of policy forking going on between wikis, maybe the whole lot should be copied to meta and deleted from all sites, including policy for individual projects such as Wikibooks and Wikipedia.

 * Visibility

I'm thinking of those signs you see on trash bins that say "keep tidy"; the locale of course depends on where you happen to be at the time. An image of that, but reading "keep wikibooks tidy" to splat on various pages, assuming we can link it to an appropriate page.

How to write effective policy documents

 * Know your audience

This is en.wikibooks.org, so users here are most likely going to be countries with a large English-speaking population, with reasonable internet access. Using List_of_official_languages and the CIA factbook:

 * India (1,080,264,388 - also Hindi)
 * USA (295,734,134 - ~82.1%)
 * Pakistan (162,419,946 - <8%)
 * Nigeria (128,765,768)
 * Philippines (87,857,473 - also Filipino)
 * UK (60,441,457)
 * South Africa (44,344,136 - ~8.2% - also many others)
 * Kenya (33,829,590 - also Swahili)
 * Canada (32,805,041 - ~59.3% - also French)
 * Australia (20,090,437 - ~79.1%)
 * Hong Kong (6,898,686)
 * Papua New Guinea (5,545,268 - <2%)
 * Singapore (4,425,720 - ~23% - also many others)
 * New Zealand (4,035,461 - also Maori)
 * Republic of Ireland (4,015,676 - also Irish)

Number in brackets is total population, which is not necessarily the same as English-speaking. Countries less than 2 million people not listed. This list is no indication of internet access. Also, some countries languages are not official languages by law, but only by custom. This distinction is irrelevant within the scope of this document.

 * Use unambigious language

Technically impossible, since all people interpret language slightly differently, but bear it in mind. Some useful tricks are:

 * Link the word to a definition in Glossary, and tighten the definition in there.
 * Link the word to a page in Wikipedia. Many words and word-phrases already have disambiguation pages there, so this may also get the point across.

 * Use examples

So, for example, when describing the correct use of naming, give an example of a book that conforms. This may be far more meaningful than any amount of explanation could ever achieve.

 * The 'wall-of-text' effect

When faced with a huge paragraph, people tend to only read the first couple of sentences, then let their mind fill in the rest. Short, bulled pointed sentences are much easier to digest. Use whitespace to break things up, and try to make policies terse, while their justification can be as verbose as is necessary to justify that policy.

 * The Bible Metaphor

Easily one of the most influential books in western civilization, and in many ways is like an early version of the, now commonplace, legislative set of rules comprising the social contract. I'm not sure if the 11th commandment was ever intended to be "Thou shalt not infringe on intellectual property rights.", but that seems to be the way things have become.

It memetic popularity can be attributed to its use of two distinct psychological tools. The first is wording it to make readers believe that they will suffer the torment of burning in eternal damnation if they don't read and follow the rules. The second is wording it to encourage the reader to propagate the meme to the minds of other people.

The practical wiki-equivalent of eternal damnation, would be things like blocking user accounts and IP addresses, and having contributions deleted or reverted. Obviously, only the latter can be performed by a regular user, and since there are relatively few admins at the moment, this may prove to be the most effective deterrent.

 * The Selfish Gene & Prisoner's Dilemma Metaphor

The psychological effect of wording the rules, to imply that a positive consequence will occur to the user who follows them, will serve better than to imply that a positive consequence will occur to the remainder of the Wikibooks community. In short, you get better results by appealing to an individual's sense of selfishness than to their sense of altruism.

Core policies

 * Definition of terms

This is extremely important. In order to communicate unambiguously, we need to agree on the same terminology. Glossary is a good starting point for this.

 * Current policy definitions

I had already added some of this to Policies and guidelines, and created the templates Template:Enforced, Template:Proposed, Template:Rejected to make it more similar to Wikipedia, but perhaps it was not such a good idea. I shall refrain from making any further changes until this is sorted out.

There are three kinds of policy:

 * Enforced policy - This will be enforced by the Wikibook community.
 * Proposed policy - This is a policy proposed to be an enforced policy, but is still undergoing discussion.
 * Rejected policy - This is a proposed policy which has been rejected by the community. It should remain to remind people why it was rejected.

When the term policy is used without one of these qualifiers, it is assumed to mean enforced policy.

A guideline is the much less formal equivalent of a policy. They generally don't require enforcement, because they're mostly obvious social behavioural guidelines in various situations. If they become problematic in the future, they may be promoted to a full policy document.

 * Existing systems

Perhaps we should use the the standards from RFC2119, since they are more tight definitions of commonplace English words:

 * 1) MUST - This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
 * 2) MUST NOT - This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
 * 3) SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
 * 4) SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
 * 5) MAY - This word, or the adjective "OPTIONAL", mean that an item is truly optional.  One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

Translated into wiki, this would mean that breaking 1 and 2 would be grounds for banning, 3 and 4 would be grounds for reverting/page renaming/merging, and 5 is just a suggestion.

e.g.

 * You MUST NOT vandalise pages.
 * You SHOULD sign posts on a talk page.
 * You MAY write a new book. :-)

In a way, a wiki is a much better system for "Requests For Comments (RFCs)", since each page has a talk page precisely for this purpose. Maybe this would be a better metaphor, but it might confuse it with the IETF documents on which it was based.

On the subject of RFCs, the success of the internet tend to suggest the IETF did a good job with writing those documents. They are very precise, and some are so well written, you could have a hard job arguing with them, except perhaps if you beg to differ on the definition of a fundamental principle like an "electron".

 * Provision nomic-esque policies

I will have to change these:

 * Every core policy is mutable (i.e. it can be changed).
 * No legal system can adapt to the changing nature of the universe without being flexible.
 * Every core policy must have at least one justification.
 * The tragedy of the commons effect would suggest that people are far less likely to follow standards without adequate justification.
 * It will prevent newbies from asking, "why is X a policy?"
 * The process for changing the core policies should be by submitting the proposed changes to its talk page. The voting process begins at this time. Each registered user gets one vote, either 'for' or 'against'. The user may in addition specify a justification for their vote, even though it may have the secondary consequence of persuading subsequent voters to vote the same way. The voting period will last for one week. After this time, if the number of 'for' votes is greater than or equal to the number of 'against' votes, the change is considered accepted, and the user who proposed the change may now apply it to the appropriate page. This includes the case where there are no votes at all.
 * By specifying a time limit for voting, things can still happen even when the site is rarely visited.

 * Issues to resolve

 * Is one week a good length of time to allow for voting?
 * Should we have another set of less-mutable standards which require a minimum number of votes to ratify?

 * Better ideas?

Anything wrong with just:

 * If you think it's wrong, just change it
 * If your change gets reverted, talk about it
 * If you still don't agree, vote on it

Seems about as pro-active as I can think of.

Navigation panel policy
Since the navigation panel is visible on all pages (is this true for all available CSS pages?), it is a useful tool for helping people find what they are looking for, especially if they have been directed to a specific page on this site, rather than to the main page or portal. These can't be changed by regular users, so perhaps a page should be put in place to specify these links, while allowing its talk page to serve as a place to discuss what they should be. Currently they are:

 * Main Page -> Main Page
 * Wikiversity -> Wikiversity
 * Community Portal -> Community Portal
 * Recent changes -> Special:Recentchanges
 * Random module -> Special:Random
 * Help -> Help:Contents
 * Donations -> http://wikimediafoundation.org/wiki/Fundraising

I'm thinking one should link to a page devoted to people who are new to the wiki experience, and that this page should provide an obvious link to the sandbox wiki.

Book writing policy
(a.k.a) How to make sure that your edits that won't get reverted by anyone, or your pages deleted by an administrator.

Obviously, it's a complete waste of time to work on a book which will subsequently get reverted or deleted.

 * Writing a new book from scratch

 * Before you start a new book, check there isn't one already which covers the scope you have in mind. By adding content to an existing book (especially if you use the correct subpage convention), rather than creating a new 'stub' book, your change will more likely be accepted by the Wikibooks community, and you will be doing a 'good thing' in trying to keep similar content in the same book.

 * When starting a new book, the most important thing is to choose a good title for it. Should you subsequently abandon the project, this title will in many ways determine its future scope, since it then becomes up to other users to determine what information belongs in it, based on its title.

 * Once you have a title for your book, try to start out with the intention of writing everything on a single page. Perhaps start with a single paragraph to explain the scope of the book. If you don't provide even this much, your work will likely get declared to be a 'stub', and deleted at a later date. To avoid this, you generally have a lot more freedom in the sorts of content you can place in your user page, or a subpage thereof. Some users prefer to start their book as a subpage of their user page, then move it to the main namespace when they think it is of sufficient quality to 'publish'. If you start your book in the main namespace, you will more likely find that other users will edit it, and might be prepared to help out with writing it.

 * As ideas for 'chapters' in the book form in your mind, start using the '==' subheading notation to subdivide it, and try to provide at least a sentence for each subheading to explain what should go in that section. Once you have at least three or four of these, the page will automatically generate a table of contents for your book. If you like, you can further subdivide with '===' sub-subheading, etc.

 * Once your page reaches the point where some of the sections contain a substantial enough amount of content to warrant a whole page to the subject, then you can start playing around with subpages. Using the '/' subpage convention will save you a lot of effort since it automatically provides links to its parent pages. Try to avoid creating links to pages that don't exist, these often get clicked on by newbies, who seem to think that "fsghfgpouhgp" is good enough for the content. Also try to avoid 'stub' pages which contain only a single sentence. Many wiki users consider these to be evil, and will often mark them for deletion, especially when they do not use the '/' subpage convention to indicate they are subpages of another book.

 * Transferring existing content to form a new book

 * First, make sure you are legally allowed to put the source onto the wiki at all. See: Copyrights
 * If the source text is already complete, and you have no intention to change it, it should be put on Wikisource instead. This site is for books in development. See also: Annotated texts
 * If the source text needs work to convert it to use wiki markup, it might be worth temporarily housing the page as a subpage of your user page. So called data dumps are generally frowned upon.

Editing policy

 * Editing policy

Deletion policy

 * Deletion policy
 * Votes for deletion
 * Votes for undeletion

 * Don't add a page to VfD unless it hasn't been edited for at least 1 week.
 * Someone trying to build up a book from scratch may take a while to get any significant amount of content in.

Namespace use policy
Personally I find the namespacing system to be a little inflexibile, since you can't dynamically add new ones, however, it might worth formalizing things like:

 * All pages about Wikibooks itself, rather than actual books should be in the 'Wikibooks' namespace.
 * Every page name in the main namespace which clearly contains no ':' and '/' to identify it as a page in a book, should be considered a 'book' in its own right.
 * If that page appears to be part of another book, please rename (move) the page to use the bookname/pagename convention.
 * Point is, if someone can't be bothered to collate the pages of their own book, they clearly need the '/' convention to provide this automatic linking for them.

There are also some pages in the 'Help' namespace, with no clear distinction as to what belongs in that, compared to what should belong in the 'Wikibooks' namespace.

Page naming policy

 * Naming conventions
 * Hierarchy naming scheme

 * On the subject of '/' vs. ' : '

There are two key differences between the two. The first is a simple typographical distinction, and the other is the way the wiki software behaves when rendering the page.

Typographically, it may be preferable to use the '/' syntax since:

 * It distinguishes it from the ':' used for namespaces, which operate in a different fashion, and may serve to confuse users as to their function. e.g.
 * The corresponding talk page for Administrators is Wikibooks talk:Administrators
 * The corresponding talk page for Programming:C is not Programming talk:C, but Talk:Programming:C.

 * It's common URL convention anyway. There are dozens of RFCs on the subject.

 * On my keyboard, I don't have to press SHIFT to make one appear. Okay. A bit selfish, but I suspect that 99% of en.wikibooks.org have the same keyboard layout as me in that regard.

Behaviorally, however, the two are not nearly as equivalent, since using '/' will create a link to its parent pages, whereas ':' will not. The user may not want this link, since they may be using a far more sophisticated template page for navigation purposes. Unless there is a way to optionally suppress the link added using '/', then you can argue that both systems need to be retained for flexibility. If there is such a system, then I'd argue for the dropping of the ':' syntax, to be used solely as a means to easily identify which namespace a page is in.

There are practical considerations as well. If we do decide to use one over the other, is anyone actually going to change all the existing books to be conformant?

See also: User talk:Aya/Wikibooks/A critique of Wikibooks

 * On the use of hierarchy generally

There is also a great deal of flexibility in the use of hierarchy generally.

See: User talk:Aya/Wikibooks/A critique of Wikibooks

Category use policy
There doesn't seem to be anything about this at the moment, and I've not really put a lot of thought into it, so I'll put in:

 * Use categories at your own discretion.

As for hierarchical categories such as...

 * Category:Wikibooks Pokédex:Baby Pokémon
 * Category:Wikibooks Pokédex:Cute Charm Ability

...or the same, but using a '/' instead of a ':' - be aware that the use of these delimiters is not interpreted by the software in any way, so it is merely a typographical distinction. For the same reasons as page naming, I would suggest the use of '/' rather than ':' to avoid the confusion between concrete namespaces and artificial scopes.

As for the conceptual 'scoping' of categories using this notation, I guess it's reasonable to do so where said categories would otherwise serve to pollute the main category namespace. This may be more necessary when creating categories based on fictional universes such as Pokémon, rather than the one we actually live in. If you merely wish to provide hierarchy to real world concepts, just choose a fairly unambigious name, and use sub-categories to create hierarchy. That is, if you add a category to another category, it is considered a sub-category of that category. Implying hierarchy through the name will only make it more awkward to modify that hierarchy later. A reasonable example might be

 * Category:Cooking
 * Category:Recipes - recipes is probably unambiguous enough
 * Category:Fish recipes
 * Category:Meat recipes
 * Category:Vegan recipes
 * Category:Kitchen equipment

The problem is, categories duplicate the functionality offered by the '/' subpage notation. The same thing could have been achieved by structuring the book thus:

 * Cookbook
 * Cookbook/Recipes
 * Cookbook/Recipes/Fish - notice here, the scope allows us to drop the word 'recipes' from the end.
 * Cookbook/Recipes/Meat
 * Cookbook/Recipes/Vegan
 * Cookbook/Kitchen equipment

I guess it's arguable which is better. You could even write your entire book in the Category namespace I guess, just to exploit its subcategory abilities.

This section has been disputed in the talk page.

Image use policy

 * Image use policy

Administration policy

 * Administrators
 * Requests for adminship

Page protection policy
In a perfect world, no pages should need to be protected, in fact, this open attitude should be strongly enouraged. Many users can be trusted to improve the formatting of the page, without changing its content, and update links which become out-of-date. In the world we live in, however, it seems apparent that some pages need to be protected. I think the real problem is not the opportunist vandals, since it probably takes them more time to vandalise a page, than it does for another user to revert it. The real problem occurs when these vandalism attempts are scripted.

So far it seems this is limited to automated linkspamming software that attempts to get higher page rankings for its pages, most likely on the Google search engine. If this is the case, then merely protected high-profile pages such as those displayed for the URLs wikibooks.org, www.wikibooks.org and en.wikibooks.org, should suffice. The first two link to Wikibooks portal (which is currently not protected, and has been targeted by linkspammers in the past), the second links to Main page which is heavily protected and monitored.

This kind of scripting could evolve into much more sophisticated vandalism attacks, which could be incredibly annyoing for the average user to revert, and would most likely require a complete database rollback. These sorts of attacks could be detected and prevented, but the current system in place may not be sufficient forever. The future solution would most likely involve the apache server keeping an eye out for many edits in a very short space of time, all coming from a single IP address. Having said that, some of these scripts are quite cunning. I've seen what I refer to as 'distributed linkspamming attacks' which come quite slowly from multiple IP addresses, to make them look like legitimate edits.

In the meantime, the current system of blocking IP addresses will have to suffice. It might be worth formalising a procedure for checking the recent edits for obvious vandalism. See Edit review policy

Edit review policy
Some sort of simple procedure for those who can be bothered to review edits for vandalism, linkspam, new pages not conforming to naming policy, uploading illegal images, etc.

e.g.: If you can't be bothered to check all edits made, perhaps just checking those made by non-registered users (vandalism attacks will most likely be from these).

 * Useful links

 * Special:Specialpages - All special pages (these need better descriptions)
 * Special:Allpages - The definitive place, I suppose, to find every page.
 * Special:BrokenRedirects
 * Special:Categories - Categories in red probably need to be created, or removed from containing page.
 * Special:Deadendpages - Probably a good place to find pages of a book which need to be linked back. Annoyingly, pages created with the '/' convention are automatically linked back, yet they still appear here.
 * Special:DoubleRedirects
 * Special:Longpages
 * Special:Newimages - Check for uploading of illegal images
 * Special:Newpages - Check for conformity of naming
 * Special:Lonelypages - Orphaned pages
 * Special:Recentchanges - Obviously
 * Special:Shortpages - For stubs
 * Special:Unusedcategories - These should probably be deleted
 * Special:Wantedpages - Perhaps references to these should be removed in skeleton documents.