Wikibooks

User:Aya/Wikibooks/A critique of Wikibooks

< User:Aya | 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

edit

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 Wikibooks: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

edit

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:

Pretty much the same meaning, so that much seems clear. Moving on to Wikibooks: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?

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

edit

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

Unreliable administrative system

edit

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. Wikibooks: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

edit

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

Solutions

The current Wikibooks: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.

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

edit

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

edit

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

edit

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

edit

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#Be bold. 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)

edit

See: Wikibooks: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

edit

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'.

Wikibooks:Staff lounge

edit

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

edit

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

edit

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 w:Dewey Decimal Classification, since it was created entirely for this purpose, and is extremely comprehensive.

Someone has already made a start with:

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

edit

See: Talk:Main Page

Wikibooks:Browse out-of-date

edit

Also it contains many red links, which is generally a bad thing.

Stub pages

edit

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

edit

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

edit

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

edit

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

Orphaned pages

edit

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

Inconsistent use of capitalization

edit

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

edit

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

edit

Mostly they talk about the page they belong to, but there are the odd cases such as pages like Wikibooks: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 Wikibooks: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

edit

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

edit

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

Provisional policies and guidelines

edit

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

edit
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
  • Wikibooks: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
  • Wikibooks: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.

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 <locale> 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

edit
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 w: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 Wikibooks: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

edit
Definition of terms

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

Current policy definitions

I had already added some of this to Wikibooks: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.

edit

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:

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

edit

(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: Wikibooks: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: Wikibooks: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

edit

Deletion policy

edit
  • 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

edit

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

edit
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'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#The dangers of page naming

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#The dangers of hierarchies

Category use policy

edit

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...

...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

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

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

edit

Administration policy

edit

Page protection policy

edit

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

edit

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
Retrieved from "https://en.wikibooks.org/w/index.php?title=User:Aya/Wikibooks/A_critique_of_Wikibooks&oldid=203708"