RFA Success

I was reading a blog post by Majorly about how broken the RFA process at Wikipedia has become. It seems to be a common topic of blogosphere ramblings, so I'll toss my own thoughts into the mix as well.

The success of an RFA system rests squarely with the bureaucrats. This needs to be a small group of people who are absolutely trusted by the community and who absolutely have the good of the project at heart. Anybody else elected to this position who does not have these traits should be removed immediately. Bureaucrats should be helpful, dedicated, inspiring. They should love the project so much that they would be willing to leave it voluntarily if they thought it would improve the project. Being a bureaucrat isn't some kind of trophy to put in the trophy case, or another badge of honor to place on the lapel: it's a promise to put the well-being of the project above any other concerns, above any personal relationships, and above any personal ambition.

That said, bureaucrats need to be both trusted and empowered to make processes like RFA Just Work. The question in an RFA is exactly this: "Is this nominee trusted enough to use the new tools to help the project?" During the process people from the community vote, optionally leaving rationales to support their votes, and then the job of bureaucrat begins. Bureaucrats need to look at each individual vote, and they need to look at the ebb and flow of overall community opinion as a whole to come up with a resolution. Here are some guidelines:

1. Reasons to promote the candidate are listed in the nomination, and the user has a track record that should be self-explanatory. Any oppose vote needs to have an accompanying rationale. Why do you not agree with the nomination? What part of the nomination specifically do you disagree with? What other information do you have about the candidate that should be known and considered? The more information you give, the more powerful and persuasive your vote becomes. Without any information, an oppose vote really isn't anything.
2. Votes should deal with the matter at hand: Is the nominee trusted to use the tools for the benefit of the project or not? Any voter whose voting rationale doesn't address this question directly isn't relevant and isn't counted. Saying "Oppose because user has only 423 edits and my algorithm requires 500" or "...because the user is a woman" or "...because the user is only 17", or "...because the user misuses commas sometimes" are all non-votes and really don't matter.
3. Any votes that are unreasonable or irrational don't get counted. This counts votes from known Friends and Enemies of the nominee who obviously vote they way they do because they publicly like/hate the person in question. If your judgement on the topic is clouded by your personal feelings, you shouldn't vote. The question isn't "do I like this person?" it's "Do I trust this person to use new tools for the good of the project?" There have been several occasions where I promoted RFA candidates who I did not like or agree with personally, but who I knew to be good Wikibookians. Notice that "Good Wikibookian" is not the same as "Agrees with my opinions about Wikibooks".

Bureaucrats need to read through the list of votes, separate the thoughtful ones from the cruft and the craziness, and render a verdict based on the needs of the community and the project, not the whims of individual editors. On Wikibooks, bureaucrats and admins are empowered (although generally discouraged from) making decisions on behalf of the project even when such a decision is against the majority of voting community members. This isn't a frequent occurance, but when the chips are down the person making the decision needs to take the available evidence (in the form of votes and their rationales) into consideration. There have been a number of VFD discussions that come to mind where the majority of people voted to "keep" a book but an admin deleted it anyway because the "keep" votes didn't adequately address any of the policy violations that the book represented. Are these tough decisions to make? Of course they are. Do admins take some heat for this when it happens? Yes, they always do.

At the end of any discussion, the question has to be "which of these two alternatives will be best for the project as a whole?". Any decision-maker who doesn't take this question into account, or who willingly answers it incorrectly should be removed from their position immediately. Because it really doesn't matter what I want, or what you want, it's what the project needs that's important. Hopefully, all your bureaucrats know that.

Guest Blog: Mike.lifeguard

The following is a guest blog post sent in by our own Mike.lifeguard. I've been trying to solicit posts from him for a while, and am thrilled that he finally sent one in. The post he sent me was originally in wikitext and I tried to convert it for blogger but I might have missed some things. If anybody else wants to post some guest commentary here about Wikibooks or Books or Wikimedia, let me know. - WK

I've been considering writing a guest blog entry for Andrew for a while now. I happened upon [[w:Wikipedia:If you could re-write the rules]], which inspired me to re-read All I Want For Christmas again & consider what I would like to see happen in the next year in terms of re-writing how we do things on Wikibooks. I've limited myself to three suggestions, but they are all on a single theme: community, which has been an ongoing topic of conversation and consternation since Wikimania 2008 to present, in particular on [[mail:foundation-l]].

We need to recognize that the community is what makes or breaks the project. I've been in contact with Sue Gardner about this, and Andrew and I had a good conversation on IRC which led to What if we... As a small project, manpower is scarce, and we've not reached critical mass yet. We need to make outreach, marketing and retention an ongoing priority at the community level. The Foundation could certainly help by focusing more broadly on all the projects (yes, I know Wikipedia is the cash cow) - and a Wikibooks Chapter might be worth creating if that level of organization is required in the future. We need to ensure the project is viable in terms of new users coming in, and retention of existing users. As well, we need to think about how to get mid- to long-term users to help with administration - we need more admin powerhouses. This also ties in with the Stanton Usability Grant since there are technical things we could do to get more editors, and some are Wikibooks-specific.

1. Keep being nice. This is what lead me from Wikipedia to Wikibooks. Since then, I've found a home on two other projects, neither of which are the English Wikipedia. Though Commons and Meta have their ups and downs (currently both experiencing a down IMO), they are full of nice people who do good work. We should learn from the mistakes of English Wikipedia, as well as the examples of Meta and Commons, which have tried to do the same, largely. In some respects they've done well, and we should emulate that. Some stuff they've tried hasn't worked; let that serve as an example for us. Instead of don't bite the newbies, we should simply not bite. I could spell out examples where this could be applied, but I think they're obvious enough already.
2. Fix the documentation in both the Wikibooks and Help namespaces. The distinction is often muddled. As well, we should have a textbook on how to use Wikibooks. Some amazing work has been done on this recently by Whiteknight and Armchair, but more is needed. We should merge existing help documentation into the relevant textbooks, and move the texts into the help namespace. Wikibookians are good at writing textbooks, and especially technical textbooks or the sort which explain how to use Wikibooks and MediaWiki at various levels: end-user, community member, administrator, devloper, sysadmin.
3. Explore alternative methods of documentation. Recently, one of Meta's best admins has essentially left the project - he was active in managing spam, so his departure dealth a huge blow to the tiny team of users who do that work. It's highly technical, difficult, thankless (actually, we get yelled at and harrassed more than we get thanked) and oft-invisible work. So, it's unsurprising that very few (read: none) wish to join us. However, I have been asked on multiple occasions to mentor people who wanted to learn about this area - I know what I'm doing and I know how to teach (having done so on both accounts for quite some time). We have lots of text documentation (and it's not even that out-of-date!), but almost nobody reads it. For those who do, it's dense reading - very easy to get lost & discouraged without someone helping you along as I had done with several users. I remembered Ben Yates' screencasts almost immediately. Despite losing my voice entirely earlier in the day, I made a ''huge'' 22-min screencast running through some basics. The 67.04 MB upload took about a half-hour - Brion was amazed it worked at all. The screencast had been downloaded from archive.org 100 times by the end of the day, and at least 4 times from Meta (which doesn't keep track, but I know because people told me).
   

Describe, Demonstrate, Do: This is a basic technique for instruction in lifeguarding (yes, I'm really a lifeguard), and other practical endeavours like using Wikibooks are little different. ''Demonstrate'' is the key that we're missing in all our attempts to teach people how to use Wikibooks so far. It should hardly be surprising, then, that users find the bar to contribute here higher than elsewhere and thus our community is not flourishing as it could otherwise.

Screencasts will be one of my ongoing projects for the year, I think. I hope to create a series of screencasts for starting your first textbook and other beginner stuff for Wikibooks, but also some of the more involved administrative areas (the spam blacklist will certainly be one). The first two suggestions require the community to be on-board, but this is one I can pursue alone and, critically, for free. Given reports from several users, I think this will be a very productive medium to experiment with. Hopefully we can work together on my other suggestions to strengthen the community for the long-term.

Organizers Needed

Wikibooks has tons of books (3000+ by some counts), but they're not all organized in a way that makes them easy to find. Last year we deprecated most of our old and unweildy organization methods: manual lists for things like alphabetical ordering, manually-maintained bookshelves, and dewey-decimal categorizations. We've switched over to a method of using categories and DPL lists to keep books organized in various ways.

The method is working very well, but is exposing some of the organizational problems that we have. Some of our books are miscategorized. Some parts of the category hierarchy are very messy or completely illogical.

We're looking for people with a good eye for consistency and a solid understanding of broad subject areas to help us organize a few places:

1. Sciences. Our science hierarchy is completely messed up, and books throughout it are commonly miscategorized.
   
2. Computing. The computing hierarchy is clearly one of those organizational systems that has grown organically in an unguided way over time. Some categories are very big, such as our generic "Programming" category. Computing books are the largest group in Wikibooks, and the one that needs the most attention
3. Humanities. It's like a catch-all for the "soft sciences" books, and clearly isn't organized well.
4. Miscellaneous. As it's name implies, it's like the de facto category for things that we just can't place otherwise. Most of the books in this category need to be moved to other places, and some new more-specific categories need to be created for these books

If you're interested in helping with some of these tasks, come on down to Wikibooks and take a look around. We'd be grateful for any help we could get.

New Book In the New Year

Getting Wikijunior's catalog of books for children improved is a project that I'm highly interested in encouraging, even if I'm not always motivated to do the work myself. You can call me hypocritical if you like. To start off 2009, I wanted to post a link to a very cool book for young pre-readers that uses images from Commons to illustrate counting like objects. [[Numbers from 1 to 20]] is a cute little counting book that presents the ideas that numbers can be introduced through counting pictures. The book isn't perfect, as there is a lot of room for improvement on the general idea, and a lot of room to improve the implementation. However, it's a great example of the kinds of books we can be developing for children using little more then well-selected pictures from the huge library of Commons.

Want to do something like this yourself? Pick a category of cool images together and arrange them into a Wikijunior picture book for kids. The best part of this is that few words are needed so people who don't consider themselves to be great artists can still participate. We've already got picture books for Numbers, Colors, Jobs, and the Alphabet. What other cool picture book ideas can you come up with to teach basic subjects to our youngest students?

Year in Review

We're getting to the bitter end of the 2008 calendar year, so now seems as good a time as any to recap the year and try to put it into perspective. Here's a brief overview of what 2008 brought to English Wikibooks:

• Added only 3 new administrators, but removed a whopping 13 of them for a net total of -10 administrators. With all the new anti-vandalism measures in place, there just doesn't seem to be a huge demand for new admins, and we've seen very few requests or nominations for the position in the last year. Many of the requests we do see are for rollbacker access instead of admin access for fighting vandalism anyway. Page deletion is really just no big deal.
  
• Added 1 new bureaucrat and 1 new checkuser. They were the same person, Mike.lifeguard. He's been a huge help at Wikibooks for a while now, and is a huge positive influence on the site.
• Added many editors, reviewers, patrollers and rollbackers. I'm not counting them all, but there were several in each category.
• Added 8 new featured books. The first wave of books came in 2007 when we first created the program, and I expected we would have a much slower rate of approval as time went on.
• We've been getting around 350,000 - 450,000 page hits per day on average, according to http://wikistics.falsikon.de/.
• Our other stats appear to have stopped updating in May 2008, so I don't have any good numbers from there.

In some respects it was a relatively slow year for us, but in others it was quite exciting. We are seeing a little bit less community participation then in the past, but more people are concentrating on their books and building excellent content. There will be plenty of time in 2009 to talk about why things are trending in this way.

All I want for Christmas

It's that time of year again, where we wrap up one year, and start setting our goals for the upcoming year. The fact that it's almost a major gift-giving holiday means that, like everybody else, I'm putting together a wishlist. Some things on the list are very practical, and some are more fantastic. Without further ado, here is my wishlist of 12 things I want for Wikibooks in the upcoming year:

1. Replace our old print versions and PDF versions with Collections. We've got javascript tools to help automate the process, and we're working on helpful documentation and templates to facilitate the process. What we need most is manpower to create collections pages and start marking the out-of-date print versions and PDF files for deletion. 2009 will be the year of the collection, mark my words.
2. Fix our damn documentation! Our whole Help: namespace is a disorganized and out-of-date mess. Our help books, Using Wikibooks and Editing Wikitext are developing nicely and are primed to become our primary help resources. I'm hoping that with few exceptions most of our Help: pages can be deleted or redirected to pages that are more current and are better maintained.
3. While we're at it, we need to clean up our sloppy category system and rethink the way we use categories to keep pages organized. Currently, they're just used as the unseen backend for our DPL-driven Subject pages.
   
4. Higher quality. We have a lot of books with a lot of content. We even have a featured books program now that helps us to pick and promote the best of the bunch. However, we judge "featured" books by relative standards. What we need are absolute quality criteria for judging books, and we need honest and unbiased external reviews to see if books meet those criteria. We need feedback from subject matter experts and potential readers to help make our books better. We need to identify the holes in our bookshelves, especially in the "core" subjects and start writing the books to fill them.
5. Usability. This topic is in vogue throughout the WMF, and Wikibooks is no exception. We need massive usability improvements as much or more then any other project. The barrier to entry is just too high to attract the kinds of contributors we need for long-term growth. I've done some javascript work that I'm proud of, but we need so much more on so many levels.
   
6. Curricula. And this is something we could work on together with the Wikiversity folks. We have lots of books targeted to specific reading audience, we need to start arranging them by grade level into meaningful curricula for students. You should be able to search by grade level and see a list of books which are written for your level.
7. Outreach. We need more active participants, and especially more people at the admin-level or higher. We need to attract more contributors who can help make the other things in this list happen.
8. Issue tracking. This is purely an idea from my own imagination, but I would like to have some kind of issue tracking system for our books. This would allow us to find tasks and report them into a queue. Interested contributors could search through the list of open tasks, take ownership of them, and work to complete them. Having a list of finite tasks and tasklets will help people to get started more quickly and gives people progress milestones. Knowing that your work is needed and that you are making real progress on things is a huge benefit to productivity and morale. I would absolutely love it if Wikibooks had an issue tracking system like Bugzilla, even if we had to roll our own with Javascript or maintain our own separate server to host it.
9. Wikibookians.org, where we could host things like an issue tracker, but also an @wikibookians.org mail server for our members. We could host advertisements for our books on PediaPress (and on Amazon if we can get them to appear there too), we could host book-related blogs and software tools that are more involved then the JavaScripts we're able to make on the wiki. I've wanted this for a long time, and 2009 could very well be the year I put it together.
   
10. Institutional support. We need to get schools and universities involved, not just as readers but as content contributors and guidance providers. We don't just write books according to our own whims and ship them out, we need to write books to particular standards. We need something like a "Wikibooks advisory board" (even an informal one) that could help guide us in making important decisions for the site and improving our books in specific ways.
11. Partnerships. We've worked with groups like the UNDP in the past when they donated a series of their e-books to Wikibooks. We need to expand that, and develop partnerships with other organizations as well. Wikibooks would be a great place for hosting things like software tutorials and documentation, or other free ebooks. Why maintain your own server for ebooks and documentation when you can host it at Wikibooks for free? I bet we could find several groups who fit this bill. I call this idea "Wikibooks as a service".
12. Design. We're working on finding a new logo, and we might even succeed this time. I would like other improvements to our site design that includes improvements to our site CSS and JS, improvement of many of our interface messages and design improvements to our main page, our main discussion pages, our policy pages, our subject pages, etc. This is not to mention the aesthetic improvements that each individual books need.

This is my Christmas wishlist for Wikibooks, what kinds of things do other people want for the project?

Nomenclature

I was talking to Pharos today, and he mentioned something that I've been mulling over for a while now in the back of my mind but never took the time to say: We at Wikibooks have a problem with our nomenclature.

Things were easy when we were just an e-book site, because we could extend the "book" metaphor to our creations with ease. A book is broken into little chunks which could be equally referred to as "chapters" or "pages". Wiki wasn't paper, after all, so it didn't matter if one of our "pages" was far longer then a single printed page would be coming out of your printer. The point was moot.

Things are a little bit different now though, because Wiki can indeed become paper in a very real way. All of a sudden we have an insurmountable wall of dense terminology where every word seems to have multiple meanings. Keep in mind that every "book" on our site has two possible incarnations: the on-wiki version and the printed PediaPress version (and even the downloadable PDF version, but let's ignore that for now).

With these two incarnations in mind, what do the words "book", "chapter", "page", "section", "unit", "module", and "heading" mean? If we keep up the metaphor and say the things on our website are "books", then what are those things that PediaPress are printing? A "page" on wiki takes up multiple "pages" in the printed book. A "chapter" in the book is made up of multiple chunks of stuff that we used to call "chapters" on the wiki. In short, we have a terminology nightmare on our hands, and as a result our best tutorials about the subject have descended into opaque and indecipherable jibberish where words are used in multiple different ways, often in a single paragraph or sentence.

And don't even get me started on the difficulty in trying to file bug reports with the PediaPress people, trying to explain how certain "features" in a published book correspond to wikitext syntax in certain places on the wiki. The fact that we've had any meaningful discussions with them is a testament to the sheer courtesy, patience and willpower that the wonderful PediaPress developers have shown. If it's this hard for us to do, I can't even imagine how confused our poor new users are becoming by this all.