User talk:Aya/Wikibooks/A critique of Wikibooks

From Wikibooks, the open-content textbooks collection

Jump to: navigation, search

Leave a comment if you wish, although I also peruse Wikibooks:Staff lounge. I'm trying to get as many opinions as possible about the way things currently work. These will eventually be translated into workable policy, and merged in to the main document, but be aware, it can take a lot of time to sort through these. - Aya 00:44, 13 July 2005 (UTC)

Contents

[edit] Once more, from the top

Note: This section copied from one of my posts on Talk:Grand Theft Auto: San Andreas, which, I guess, is where all this started. Note that some of my conclusions were subsequently altered. I shall merge in the more pertinent parts when I have time. Please don't add replies to this section. - Aya 18:34, 13 July 2005 (UTC)

Okay. I think we both have different interpretations of what Wikibooks actually is, and the most effective means of using it. I guess it was rather a dumb idea of mine to choose some standards without adequately justifying those choices. This almost always fails to produce standards which get adhered to, in any system where people are not rewarded for following said standards. e.g. In a company, you get paid money to follow their rules. On a wiki there is no obvious financial reward at all. But I hope you at least agree that standards are important on collaborative projects, if only to the extent that we interpret language in the same way. i.e. We share a common 'dictionary'.

For what it's worth, I'm a 28-year-old software developer, and during some of the projects I've had to 'endure', I came across various pitfalls of the processes commonly used within those projects. Most of these don't really pertain to wiki, but some do. I also fairly new to the wiki community, but I really like the idea, because it does to information what web-forums and newsgroups can only dream of.


[edit] The dangers of page naming

I've finally read through all the material I can find about page name delimiters, and I'll just summarise what I've found here:

N.B. I use the character '*' to represent any amount of whitespace, including no whitespace. Valid whitespace characters seem to be: '_' and '%20', but not ' ', since this is an illegal character in a URL. All browsers convert it to '%20'.

page name -> wiki interpretation

"*GTASA*" -> a page in the global namespace named "GTASA"

"*Talk*:*GTASA*" -> a page in the "Talk" namespace named "GTASA"

"*GTASA:Ryder*" -> a page in the global namespace named "GTASA:Ryder"

"*GTASA:_Ryder*" -> a page in the global namespace named "GTASA:_Ryder"

"*GTASA/Ryder*" -> a page in the global namespace named "GTASA/Ryder". Provides a link to "GTASA"

"*GTASA/_Ryder*" -> a page in the global namespace named "GTASA/_Ryder". Provides a link to "GTASA"

"*GTASA_/_Ryder*" -> a page in the global namespace named "GTASA_/_Ryder". Provides a link to "GTASA"

Notice the last three are conceptually identical, but will return three different pages. Not really what we want.


[edit] The dangers of hierarchies

Hierarchies are probably most familiar in things like URLs. The idea is to use them when something is conceptually a 'child' element of another element. This is great for some applications, but the problem is that with a bunch of disparate concepts, as you might find in a guide for GTA:SA, it's nigh impossible to get everyone to agree which means of arranging things in a hierarchy is best.

e.g. I noticed above that the page 'Vehicle Missions' is a child of the 'Vehicles' page, whereas since it's ultimately talking about missions, and not vehicles, I might have decided to make it a child of the 'Missions' page.

The same is true for most classification schemes. Let's take an example for movies. If I decide on some categories like 'Action', 'Drama', 'Comedy', 'Horror', 'Sci-Fi', etc.

The problem now is that when I want to add a movie to one of these categories, which one should I choose? The movie 'Pulp Fiction' surely belongs to more than one of these categories.

The error here is defining categories which are not mutually-exclusive. A good example of categories might be 'A', 'B', 'C', etc., in which case, there could be little argument that the movie 'Pulp Fiction' should belong in the 'P' category.

Categories also fail where the category names are poorly defined, as they are right now.

Furthermore the hierarchy might change as new content is added, and if this hierarchy is included in the page name, then the page name will have to change also. From my experience, it's a lot easier to change the content of a page, than it is to change the page's name.

Another problem with using the '/' notation is the implication that the parent node MUST exist. I might want to have a page "foo/bar", but not a page "foo".


[edit] Conclusions

To avoid confusion, I shall define the following terms:

bookshelf
Conceptially, an index of one of more categories of books on Wikibooks.
book
This is perhaps analagous to a paper book. This book may belong to any number of bookshelves.
page
This is perhaps analagous to a chapter in a paper book. Note that one of the design goals of Wikibooks was to allow many books to share the same pages. e.g. Most of the Wikibooks relating to computer programming, tend to include the global page containing the ASCII chart.
page name
The suffix of the URL used to retrieve a page. i.e. http://en.wikibooks.org/wiki/page name. Note that many similar suffices may be used to reference the same page, so I shall define it to mean the shortest suffix required to retrieve the page.
content page
Conceptually, perhaps, a leaf-node page which contains mostly useful content pertaining to its page name.
index page
A page whose primary reason for existence is to provide an index to other pages. The index could be hierarchical, alphabetical, or whatever. A bookshelf page is an example of such a page.
  • Use page names solely to uniquely identify discrete concepts within the scope of the book. They should not be used to denote hierarchy.
  • Keep the page names as short as possible, while making every effort to avoid namespace collision, by using scoping or disambiguation where necessary.
  • To provide a hierarchical model of all the content pages relevant to the book, use an index page to index the existing content. This is the current purpose of the 'Contents' page. If the conceptual hierarchy should need to change, you only need to modify that one page. This also allows you to apply multiple conceptual models to the same information, simply by having multiple index pages. e.g. the 'Index' page will ultimately provide an alphabetical index of the same content pages, and the FAQ page is starting to link back into the main content.
  • To provide a hierarchical model of all the content pages relevant to a smaller scope (e.g. all missions in Los Santos), use another index page.
  • Try to avoid changing the page names of existing pages, or creating too many new content pages until there is a clear page naming standard.

Perhaps it would be clearer if I specified how I ultimately expect the pages to be named. The string "GTASA" should be interpreted as "Grand Theft Auto: San Andreas":-

  • Index pages
    • "GTASA" - Main page, linking only to other index pages.
    • "GTASA: Contents" - Full hierarchical contents, linking to every content page.
    • "GTASA: Index" - Full alphabetical index, linking to every content page.
    • "GTASA: Frequently Asked Questions " - This page is a little hairy, since it contains both indices and content, but I shall put it in here in the hope that ultimately it will only contain links to other pages.
    • "
  • Content pages
    • "GTASA: Mission: Ryder" - Anything pertaining to the 'Ryder' mission.
    • "GTASA: Mission: End of the Line" - Anything pertaining to the 'End of the Line' mission.
    • "GTASA: Character: Ryder" - Anything pertaining the the character 'Ryder'
    • "GTASA: Vehicle: Infernus" - Anything pertaining the the vehicle 'Infernus'
    • "GTASA: Item: Night-vision Goggles" - Anything pertaining the the item 'Night-vision Goggles'

If you think having only a single index to all missions is too much of a 'spoiler', then you could create another index page, say, just for Los Santos missions, which would link to the 'Ryder' mission, but not to the 'End of the Line' mission.

The means used to disambiguate the page names is arbitrary. I merely chose the colon (as used typographically rather than in a scoping context. i.e. "foo: bar" rather than "foo:bar"), because this seemed to be the way that the content was already organised. Some other examples:

  • "GTASA: Ryder (mission)"
  • "GTASA: Mission - Ryder"

I really don't care which method is used, providing it's agreed upon. Maybe the colon is a bad idea because it implies a namespace where none exists.

See also: Wikibooks:Naming_conventions

Okay. It's 8:00pm here, and I'm off to the pub for a while.

Aya 18:56, 16 Jun 2005 (UTC)

I wasn't aware that there was a misunderstanding at all, but now I finally see what you're getting at! Yes I did think of the hierarchy of the Vehicle Missions--after I'd moved it! Certainly it should go under missions.
But what other examples are there of multiple-location pages like the Pulp Fiction example you gave? From a quick look at the list, pretty much everything might as well stay right where it is until such time as good names are found for "collectible hidden things" and such. For neatness' sake the Burglary guide should go under the Vehicle Missions page, but, again, that's minor.
As for implying the parent exists, in the currently applicable situations I can't think of a parent directory that would be unwanted, except for /Cheats/ but I've got plans for content there too.
The colons as they look nice and make nicer-looking page auto-titles than the slashes do, but they still imply an upper directory exists. Brackets make users less inclined to think there is a higher level, but as a downside they generate ugly URLs ("Grand_Theft_Auto:_San_Andreas_%28Contents%29").
I'm interested in using slashes because that is the standard for nested pages both in many of the other books here and the pages on other Wikis. Also, and more importantly, the MediaWiki engine will eventually support a TOC link on each page that will generate a list of its child pages, but this will not however support colon-based directories. Therefore for future-proofing and overall cohesiveness with the style adopted by the rest of the Wikibooks projects it seems the slash should be the way to go. Hmmm...
But hang on, I've got an idea, I'll just post this and do that :) Master Thief Garrett 14:22, 17 Jun 2005 (UTC)


[edit] Other bits to be merged


[edit] Category hierarchies

From the main page: The problem is, categories duplicate the functionality offered by the '/' subpage notation.

This is incorrect. In the cookbook, the recipes fit into many different categories, e.g. a recipe in Category:Vegan recipes and in Category:Bread (see: Cookbook:Cardamom Bread). Kellen 01:48, 13 July 2005 (UTC)

You're correct of course. We really need a good policy on use of categories. They're just too flexible for their own good. Maybe it's no big deal, and "Use categories at your own discretion" is about all we can say. I guess they can always be moved or renamed later on if there's a conflict. It was so much easier on Wikipedia, since there could be fewer arguments about the correct use of categories. It's almost as if each book on Wikibooks would benefit from having its own namespace, with its own pages, categories, images, and templates in that namespace. Another way of saying it is, perhaps with the current software implementation, each Wikibook needs its own wiki, in the same way that Wiktionary and Wikipedia are effectively separate books in their own right, but both theoretically could have been separate Wikibooks projects on this site. I suspect there would be many advantages from having all WikiMedia projects sharing the same wiki, providing the MediaWiki software could keep them all separate. Intra-wiki-linking feels much more professional than inter-wiki-linking. - Aya 14:36, 13 July 2005 (UTC)

Where hierarchical categories come into play is where there are managment issues in the categories. In the main wikipedia this is not so much a problem since everything belongs to the same "book." In the cookbook we have lots of stray categories with only one or two things, many of which are not subcategories of the "main" cookbook categories. If we make sure that we prefix everything category for the cookbook with "Cookbook:", this mangment becomes much easier. Kellen 01:48, 13 July 2005 (UTC)

I can't see a conceptual difference between making those categories subcategories of the 'main cookbook' categories, and altering their names to make it look like they are subcategories (regardless of whether you subsequently add them to be bona fide subcategories too.) Having said that, and based on my previous reply, it might be worth prepending them anyway, to serve as a scoping tool to prevent namespace collision, rather than implying a hierarchy. Perhaps the following might be useful:
For a book entitled "foo", the following page prefixes are reserved for that book:
(Main:)Foo[/*]
(Main:)Foo[:*]
Talk:Foo[/*]
Talk:Foo[:*]
Image:Foo[/*]
Image talk:Foo[/*]
Template:Foo[/*]
Template talk:Foo[/*]
Category:Foo[/*]
Category talk:Foo[/*]
Only use pages outside these prefixes where they are conceptually designed to be shared between multiple Wikibooks. It may also be worth listing these generic pages on another page, so people are aware of them, and don't accidentally create a fork.
This is part of WB:NC (although images, templates, and categories are in recommended use only), although it is not strictly enforced because little effort has gone in by users to enforce them. KelvSYC 04:26, 14 July 2005 (UTC)
Wow. I accidentally came up with the existing policy without having read it. "Great minds think alike" or just "blindlingly obvious"? Yeah. It's obviously not a followed convention for those who have never read it. - Aya 13:25, 14 July 2005 (UTC)
In a way this seems like common sense, but it's not written down anywhere. Note that I only allow the ':' syntax for pages in main and talk namespaces, since it's the only one which provides different wiki behavior. I still believe the '/' is typographically preferable. I already used this convention with the page header template Template:Grand Theft Auto: San Andreas/Header for the book Grand Theft Auto: San Andreas. - Aya 14:36, 13 July 2005 (UTC)

My inclination is that categories probably shouldn't be shared across wikibooks anyway, though maybe entire wikibooks could be categorized together (Category:Physics books). Kellen 01:48, 13 July 2005 (UTC)

Again, you're probably correct. I guess there has to be a distinction between the categorization of books, and the categorization of pages within a single book. Back to your original question, I'd go ahead and create categories of the form 'Category:Cookbook/Meat recipes', etc. I guess it's probably worth including them all as subcategories of 'Category:Cookbook'. - Aya 14:36, 13 July 2005 (UTC) Check out The movies example to see if we are even talking about the same thing. - Aya 13:35, 14 July 2005 (UTC)

confirming bugzilla:2833 fixed Kellen 01:48, 13 July 2005 (UTC)

Wow. Thanks. That was quick. It just works now. I'll add in a bug-reporting policy, just so that everyone knows the proper procedure. i.e. they go to http://bugzilla.wikimedia.org/. - Aya 14:36, 13 July 2005 (UTC)


[edit] Test Wiki

You can find a test wiki here.

http://test.leuksman.com/index.php/Main_Page

It's running MediaWiki 1.5, indeed was running it long before any other project. So that's basically one BIG sandbox to make use of.

There, one problem solved already! :) GarrettTalk 04:54, 13 July 2005 (UTC)

Cool. 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. I'm beginning to think Geocachernemesis was right, and that I should move all this stuff to meta.wikimedia.org. - Aya 14:37, 13 July 2005 (UTC)
Update: merged into User:Aya/Wikibooks/A critique of Wikibooks#Newbies - Aya 18:34, 13 July 2005 (UTC)
By the way, how d'ya get that different signature to work without using a template? - Aya 18:34, 13 July 2005 (UTC)
Look in your Preferences. My nickname is set to [[User:Master Thief Garrett|Garrett]]<sup>[[User talk:Master Thief Garrett|Talk]]</sup> but "raw signatures" must be checked or it tries to re-bracket it.


[edit] The movies example

See: The dangers of hierarchies

Talk moved from that section:

In your example here for movies, my current view of things would be to make the movie pages distinct from any hierarchical page naming except for the top-level namespace (e.g. Movies:The Blob), then have your structural book pages as necessary (e.g. Movies/Horror and Movies/Sci-Fi), have appropriate categories (e.g. Category:Movies:Horror and Category:Movies:Sci-Fi), include Movies:The_Blob in both these categories and link to the category listings from the structural pages. This is not without its problems -- say if you wanted extended descriptions of the movies on the listings page, or you wanted to have more defined categories.

I agree with "Movies:The Blob", but I might prefer "Movies/The Blob" to get the auto-link. The use of categories is obviously correct for this example, although I would've chosen the names "Category:Horror movies" and "Category:Sci-Fi movies", and added them both to the category "Category:Movies". But I don't understand why you need the pages "Movies/Horror" and "Movies/Sci-Fi". - Aya 19:07, 13 July 2005 (UTC)
In the current paradigm you'd want "Movies/Horror" or "Movies/Sci-Fi" as detailed descriptions of the genre, but you'd have "Category:Horror movies" to actually catalog all of the horror movies. In reality, you could put your detailed description on the catagory page, but that doesn't seem to be current practice. I'm actually inclined in some instances in the cookbook to make the category pages more like these "normal" pages, especially where on the pages there are listings of recipes Cookbook:Vegan cuisine for an example. If the "Vegan cuisine" page was actually a category page, you'd automagically get the listing of recipes and subcategories below. Kellen 00:50, 25 July 2005 (UTC)
I'd be inclined to agree with your idea of adding more detail to the category pages, rather than creating new pages for the detail. I'm sure this was how they were intended to be used, since otherwise, I wouldn't see the point of the software forcing you to create the category page solely to list the entries in that category. It subsequently occurred to me that if category pages can be used in this way, and also have the benefits of subsetting, why would you ever need a regular (non-category) page? A regular page strikes me as being a category page that you can't add subcategories to. I also wonder as to the reasoning behind having a separate template namespace, although it may be purely for performance reasons (i.e. changing a template page forces the software to flush its cache for all pages which include that template). - Aya T C 02:46, 25 July 2005 (UTC)
"changing a template page forces the software to flush its cache for all pages which include that template" is not true in the case of categories. You must do a null edit on each page which includes the template in order to flush the cache. See the meta help page for more info. Kellen 08:57, 25 July 2005 (UTC)

You may want a movie to be in Category:Movies:1980s and Category:Movies:Horror, but as far as I know, there's no category intersection pages... /ramble Kellen 18:02, 13 July 2005 (UTC)

This may be the point of confusion between us, since as far as I was aware, there is such a feature, and its unique to categories. As well as adding a category tag to a regular page, you can also add the tag to a category page. In this case, the category for the page you added the tag to, is considered to be a sub-category of the category name specified in the tag. When you subsequently click on the super-category, it will list not only the pages in the category, but also all it's subcategories. If you were unaware of this, it was the reason I gave for why category names should not imply hierarchy. See Category:Science for an example. - Aya 19:07, 13 July 2005 (UTC)
I mean something different.
First, some other observations: When you make a category a subcategory of another category (yeesh), you're essentially including all the pages in that category in the supercategory. The pages in the subcategory do not show up in the pages listing in the supercategory. It is implied that they would also belong there, but there's no way to view all of them at once (so far as I know). This is problematic for, say, recipes, where you might sometimes not care about the category structure, and you just want to see all the recipes that fall under Category:South American recipes, for example. The interim solution for us is to add everything to Category:Recipes to create a big index. This is getting unweildy though, so I think I might move them all into Category:Recipe and leave the subcategories under Category:Recipes.
What I was specifically referring to above is that if I have two distinct categories which have pages in common, there is no way to filter my view so that I see only the recipes that belong to both. This comes into play in the cookbook where we have Category:Soups and Category:Vegan recipes. There is currently a Category:Vegan soups, but this seems wrong to me. The correct way would be to file the recipe under both "Soups" and "Vegan recipes" and then get a view which is limited to things in both of these categories instead of replicating all of the possible food types (Soups, Desserts, Mains, Peruvian recipes, etc) with "Vegan" prefixed to them. I realize that "Vegan soups" can be categorized under both "Vegan recipes" and "Soups" but that still strikes me as redundant work. Kellen 01:03, 25 July 2005 (UTC)
Ahh. I see. Perhaps substituting the word 'category' for the word 'set' might make things clearer (i.e. formal set theory). Thus you can have a set of soups and a set of vegan recipes, but there no way to automatically generate an intersection of the two sets (i.e. the set of all vegan soups). In addition, you can have a set of meat recipes and a set of fish recipes, but you can't generate a union of the two sets (i.e. the set of all meat or fish recipes, probably equivalent to the set of all non-vegitarian recipes). Furthermore, the elements of a subset are not shown in a superset, which might be considered more 'correct' in set theory.
This would no doubt require a software change, and a new syntax for creating unions/intersections, and perhaps an option to show entries in all subcategories. Sounds like a neat idea, and might be worth suggesting to the dev team, although I suspect you probably know better than I how to do this. I'm beginning to think I'd be better off joining the dev team, and fixing things in there, rather than creating extensive documents to workaround these issues.
Regardless, I still don't think that implying hierarchy in categories by their name is a good idea, since it conceptually duplicates the behavior of subcategories. The original Pokemon example is perhaps a special case, since it deals with a fictional universe. I see that more as 'scoping' to prevent namespace collisions, rather than 'hierarchy', although they can be argued to be conceptually equivalent. - Aya T C 02:46, 25 July 2005 (UTC)
Agreed in most instances. The main thing I am concerned about is whether the categories should be scoped to the book or not. I tend to think that they should, but that the books should be categorized (mentioned this before). A potential problem with this approach is that at some point someone may wish to categorize related chapters in different books, but I think this is a rather minimal downside for having a clean category space. Kellen 08:57, 25 July 2005 (UTC)

[edit] Be bold

Having said what you said in your critique, why don't you be bold and try to fix some of these problems that are plaguing Wikibooks? KelvSYC 04:36, 14 July 2005 (UTC)

The point of writing the document was to mostly to serve as justification for any subsequent changes I make, so that when my actions get questioned (as they no doubt will), I don't have to tediously explain the same point to several different users, but rather give a link to the document. Futher, as I stated in Wikibooks:Staff lounge, I was going to make some changes, but it would be fair to consult other Wikibookians before doing so, which I'm hoping this talk page will become. It just seemed logical to keep a record of my train of thought, to make it easier for other users to identify any flaws in my reasoning.
The fundamental problem I have identified is that the current policy documents are numerous, invisible, vague and self-contradictory. That is why people keep discussing their meaning so much. In order to solve the problems, I figured the best procedure would be:
  1. Identify the problems with policy
  2. Identify the causes of the problems
  3. Solve the problems, by eliminating the cause where possible
  4. Devise new policy to implement the solutions in a practical fashion
  5. Make sure people agree with the new policy, to prevent my edits getting reverted
  6. Update the policy documents to prevent future misunderstanding
  7. Make sure the policy is more visible to new users, especially those creating new books
  8. Retroactively apply new policy to existing books
There seems little point in performing the final step as long as the policy is unclear. New books are being created all the time, and I just don't have time to fix them all. - Aya 13:10, 14 July 2005 (UTC)
So far, the only policies actively enforced are WB:WIN (the constitution if you will), WB:FP, and WB:AT, although there is an increasing amount of WB:NC enformcement. Other policies are pretty much common to all MW wikis (deletion, editing, etc). KelvSYC 06:39, 15 July 2005 (UTC)
Aha. I think I've found one of the sources of confusion. See this diff, made by yourself. You completely changed the meaning of the document, by changing the more specific term "primary research" (adequately defined), with the incredibly vague term "original research". Its new definition arguably covers every existing book on the site. This needs to be fixed. WB:FP is common sense, especially for software-engineering people link myself, but needs to remain, and ought to tightened up (especially forking from Wikipedia). WB:AT should probably be merged into WB:WIN. WB:NC is a bit more fuzzy at the moment, especially as it starts with a link to WB:HNS. WB:WIN is a bad idea for a 'constitution' anyway. It's much more effective to define what something is, rather than define what it is not. I'm thinking of something more akin to User:Aya/Wikibooks/A critique of Wikibooks#The goal of Wikibooks - Aya 08:16, 15 July 2005 (UTC)
Perhaps the diff you have shown introduces ambiguity, but the current version of WB:WIN does not have it (thanks for User:Dovi who pointed it out in the talk page). It should still reflect the spirit of what it is meant.
Most of the policies are fuzzy because they are not well fleshed out (or in dire need of enforcement). Historically, I believe WB:AT is separate due to this being an agreed-upon policy between Wikibooks and Wikisource. I will be the first to admit that perhaps WB:WIN is a "bad idea", but we need a series of pages that will define what Wikibooks is (of course, I will ask you to contribute in a big manner, seeing you have your ideas and seem to be willing to implement them).
Of course, with radical changes to Wikibooks as we know it, we may have to relent on existing policies and introduce. I admit that I can be considered "old guard" as these changes may change the mission of Wikibooks, but if the public likes the wiki to go that way, they may force our hand. Among these we would need:
  • Wikibooks:Reference material for what constitutes general nonfiction books (as opposed to, say, Wikipedia articles or books of a nonfictional material). This would form the third part of defining what appropriate Wikibooks should be.
KelvSYC 05:20, 26 July 2005 (UTC)
Pah. Now we have the same conversation going on two pages. I've just replied to your post to the mailing list on your talk page. Let's shift it to there for the moment. - Aya T C 17:57, 26 July 2005 (UTC)

We could sure use someone to enforce WB:NC to General Chemistry or determine through WB:FP what parts of Programming:C plus plus and Programming:C -/- -/- to keep in a merged book (both long debacles that has existed since well before I was a user, let alone an admin). KelvSYC 04:36, 14 July 2005 (UTC)

I was aware of these problems, and they do need to be addressed, but the problem will only get worse as new users create more pages making the same errors. I already made to effort to apply the new naming conventions to the Grand Theft Auto: San Andreas guide, as well as all the other tidying up required to cope with the changes, and it can take a long time. Feel free to 'be bold' yourself if you want these other books changed more speedily, but I would probably first devise a scripting system for a bot to make these changes. Probably only needs 50 lines of perl (not that I recommend perl, but it is well known). - Aya 13:10, 14 July 2005 (UTC)
Pratically all MW bots use Python by the way. KelvSYC 06:39, 15 July 2005 (UTC)
Yeah. I had seen the Sourceforge project. I much prefer Python to perl. I have personally submitted source code corrections to it before. Since it's the most common, I tend to use the word "perl" to mean "any scripting language comparable to perl". - Aya 08:47, 15 July 2005 (UTC)

The problem is that not a lot of users venture out of their own book, and it would be great if you would be one who helps keep things orderly rather than complaining about how things aren't. KelvSYC 04:36, 14 July 2005 (UTC)

I'm not complaining, and it worries me that you interpret it as such. Be aware that the word "criticism" does not necessarily imply a "complaint". I'm just trying to sort things out. I'm just not sure that I've come up with the best method yet, and I don't want to change anything until I am. - Aya 13:10, 14 July 2005 (UTC)

How about rather than putting down stuff like {{proposed}} or {{enforced}} in every policy page, go out and just enforce these policies? KelvSYC 04:36, 14 July 2005 (UTC)

To be fair, that template stuff was probably a mistake. It's no worse than it was before, but it's only marginally better. Since most of the policies here have been (inappropriately) forked from Wikipedia, I figured I'd copy Wikipedia's current system for policy, hoping it might make a difference. I was wrong. Problem is there are far too many policy documents, they are not always clearly identified as such, and no-one has actually read them all. I feel a massive merge and delete operation coming along soon.
On a personal note, can I inquire as you your age, sex and location, since it's not on your user page. It might be easier to communicate, since I could alter my dialect to use metaphors more common to you. (e.g. using the US Constitution as a metaphor is obviously more effective for people of US origin). - Aya 13:10, 14 July 2005 (UTC)
I'd rather not disclose that here, for personal reasons, although you will invariably find what you are looking for on the MW projects. KelvSYC 06:39, 15 July 2005 (UTC)
Apologies for not looking. Your Wikipedia user page is slightly clearer, and tends to indicate you are a Canadian immigrant from a Chinese-speaking nation. Based on your contributions and use of language, I'm guessing that you are male, and between the ages of 14 and 24. - Aya 08:16, 15 July 2005 (UTC)

[edit] English language

English is not the official language of the UK. There isn't one! Although, of course, it is conventional to speak English. See the article on the United Kingdom on wikipedia. --Mark Lewis 14:24, 19 July 2005 (UTC)

Thanks for the correction. I've updated User:Aya/Wikibooks/A critique of Wikibooks#How to write effective policy documents appropriately. - Aya T C 17:40, 24 July 2005 (UTC)

[edit] Revising Wikibook policy standards

OK, I'm going to betray my ethnic background somewhat here, but my country got into a big pickle when we tried to adopt previous institutions that were inherited from the "parent" country, and found out the hard way that the whole thing was so screwed up that it was totally unworkable. In short, we tossed out the entire body of law and started anew. The resulting document was the United States Consitituion. - Rob Horning 04:38, 24 July 2005 (UTC)

First of all, a sincere thankyou for your extensive, and well thought out contribution. Based on your comments and your apparent timezone, I'm assuming you're a US citizen, and the 'parent country' to which you refer is the UK. Please correct me if I'm wrong. - Aya T C 18:19, 24 July 2005 (UTC)

In the same vein, Wikibooks may have to do exactly this as well. We know the founding principles of what got Wikibooks going, and I don't want to betray that at all. At the same time, this is not Wikipedia, and there needs to be a way to "declare independence" from Wikipedia and its policies as well. We are still under the umbrella of the Wikimedia Foundation, but it is only the Wikimedia board that we should be obligated to please.

Furthermore, there has been a couple of years of hard won experience here at Wikibooks. What has worked, what hasn't, and where should we go? In this regard you are doing us all a big favor Aya, by taking this issue by the horns and trying to make something of this work. The #1 issue that I would see, however, is that something of this scope needs to include more than just en.wikibooks. We need to get the other languages involved in setting general broad policies governing Wikibooks and its relationship to the other Wikimedia sister projects.

I've long complained (for a couple of months or so, I guess) that Wikibooks has become the dumping ground for projects that the other sister projects don't want to deal with. The 1911 Encyclopedia is a classic example of this, and was (unfortunately) suggested by one of the participants on Meta. By establishing firm policies as to what is and is not proper content that can be placed on here, we can clean up Wikibooks and make it a jewel that it can become.

Wikibooks is also at a transition. New blood is coming into Wikibooks, and there seems to be a slight clash of cultures going on right now. As for myself, I would not have been involved with Wikimedia projects if it weren't for Wikibooks. I looked at Wikipedia several years ago (more than one), and even poked around at the content, but never felt compelled to get involved. After reading several Wikipedia entries from Slashdot, and an article about Wikibooks, I finally had a book idea that was digging into me and I had to write. Programming:Serial Data Communications is the result of that initial effort (and I'm not done). - Rob Horning 04:38, 24 July 2005 (UTC)

Seems as if you've pretty much come to the same conclusions as I. I had taken a slight break from writing this document, while I did some research on other Wikimedia projects, to see how they deal with these problems. During this time I discovered extreme content overlap with other wikis, and have tried to address these by creating m:Directory as an authoritative index of Wikimedia projects, languages, wikis, and appropriate content. As for authoritative policies, I've made a start on m:Policy; the idea being to move all policy, and debate thereof, from each individual project, to Meta. I feel as if this was the intended purpose for Meta anyway (read m:Meta:About). In effect, this would mean that most pages in the 'project namepace' (e.g. the Wikipedia namespace on the Wikipedia project) ought to be moved to Meta.
The main problem I am now facing is the classic 'tradition' vs. 'evolution' conflict. (e.g. w:Wikipedia talk:Bad Jokes and Other Deleted Nonsense#Votes for Transwiki). It seems people would rather carry on in the current tradition of chaotic scope and policy, rather than allowing it to evolve into something more meaningful and well-defined; the reason being that for convenience, long-term users would prefer things to stay the same, whereas new users would prefer the content to be in more obvious locations. In this particular case, perhaps the correct thing to do would have been to just ignore what other people think, be bold, and just do it, but I have a feeling my changes would be reverted, and it would thus be a waste of my time.
The other problem is that Meta is a complete mess. There are too many pages which are out-of-date, and too many on the same subject which contradict each other. I'm beginning to think Meta needs to be redesigned from the ground up, but I don't think it's something I can get done by myself. I'm still pondering various ideas, but in the interim, I'd be grateful for any suggestions you might have on the subject. - Aya T C 18:19, 24 July 2005 (UTC)

Carry on, Aya. I'll try to make some comments about some specific points you have raised later. - Rob Horning 04:38, 24 July 2005 (UTC)

That would also be appreciated. I stick by the idea that even where pages should contain all users POVs, it should retain a single editor (preferably one who is well-versed in the finer points of language) to ensure it has a meaningful structure, and maintains consistent language use throughout. - Aya T C 18:19, 24 July 2005 (UTC)
Retrieved from "http://en.wikibooks.org/wiki/User_talk:Aya/Wikibooks/A_critique_of_Wikibooks"