Perl 6 Programming

I mentioned this issue on the wiki a while back, but haven't made any kind of public announcement about it until now. I was selected to receive a "Perl 6 Microgrant" to write a book on Wikibooks about the new programming language "Perl 6". The money involved isn't whoo-hoo fantastic, I'm not going to quit my day job over this. However, I'm not really in this for the money anyway. I work on Wikibooks because I genuinely want to do it and enjoy doing it.

There are two free-culture projects that I participate in regularly. One is Wikibooks. The other is an open-source software project called Parrot. Parrot is a virtual machine, similar in many respects to the Java virtual machine. However, instead of running Java, Parrot aims to support a wide variety of dynamic programming languages like Perl, Python, PHP, and Ruby. My work on that project has inspired my work on a related book: [[Parrot Virtual Machine]]. This also put me in touch with some of the people doing work on the compiler for Perl 6, a compiler which is targeting Parrot. They asked for people to submit grant proposals, I submitted one. Waited a while. Got the grant.

On one hand we have plenty of people who get paid to do their work on Wikibooks: The teachers, professors, and graduate students who are writing and organizing some of the class projects that we host, or the researchers to receive grant money to do research related to Wikibooks. On the other hand, I'm the first whose [publicly] been getting money specifically to just write books without being part of a larger job. It's an interesting situation, but one that hasn't drawn any level of controversy at all from my fellow Wikibookians. They've all been very supportive, making vague warnings on one hand about avoiding possible conflicts of interest, but being excited about all the possibilities that this opens up on the other hand. imagine if more people were making money to write good-quality books on our site? Imagine if there were more grant money available to fund people to work on books? This happens with some regularity in the open-source software world, so it's not a big stretch to think we could leverage the almighty dollar to make things happen at Wikibooks too.

As part of the grant, I'm writing regular updates (weekly or bi-weekly, depending) on my use.perl blog. I also post some technical updates about my programming work there too, so forgive me if it's not suitable for a general audience.

I would love to hear feedback about this project. What do people think about funding for writing books? What do people think of my work on this particular book? Do people think that maybe Wikibooks could be more proactive in this area?

FlaggedRevs Review

I've seen a lot of blog posts today about how English Wikipedia is preparing to get the FlaggedRevs extension installed. I think that's a good idea, English Wikipedia is a project that could really use it to great effect to improve it's reliability and decrease it's spam volume.

At English Wikibooks we've had that tool for a while now, and some of us are starting to question whether it's suiting our needs appropriatey. There have been plenty of complaints about our autopromotion requirements for +Editor (I can't even tell you what the current requirements are, since they are so complex). I've advocated drastic reduction of the requirements (after 10 edits or so), although some people have said that we should just tack +Editor on at the same time members get autoconfirmed, which is a simple 4 day timer. I like that idea too, although I'm not sure it is going to perform the promotion quickly enough.


We've also been worrying that we don't quite have a large enough community to support this tool anyway. The list of pages that have been reviewed is certainly growing, but it's woefully small compared to the total number of pages we have at Wikibooks. We just aren't reviewing pages quickly enough, and I'm not even sure that we're reviewing pages as fast as we are creating them. Of course, if we have more +Editors who are automatically sighting pages with every edit, that number will increase pretty dramatically.

Also, as if we need more factors to worry about, we need to think about whether or not our current grading metrics are sufficient. We have three metrics now: Composition, Accuracy, and Coverage. These are nice, but they don't necessarily cover all the things that we might want to look at. Also, I find there are lots of areas of overlap: Accuracy tends to go up as we get more coverage, and the quality of writing goes up with volume too. Being more accurate also requires more precise and higher-quality writing. In short, it's rare to get a bad grade on one if you've gotten good grades on the other two.

We have questions to ask, and questions to answer. Plenty of things will definitely change, and maybe we as a community might decide to uninstall the extension entirely. We'll see how things play out.

Collections Podcast

Mike.lifeguard forwarded a link to me today, a YouTube screencast about how to create a collection and print a book:

http://www.youtube.com/watch?v=7S0UsTvW6IM

If anybody has any other cool videos or links related to Wikibooks, I would love to see them.

New Logo!!!

It's finally official! It's officially final! All those haters out there who said we would never do it can eat their words: Wikibooks finally has a new logo!

Come on down to Wikibooks and take a look at the brand new logo. We're quite happy with it.

Trades and Crafts

I created a new subject page today in my effort to try and rein in our jumbled miscellaneous section. The new subject, Trades and Crafts, is intended to hold information about various skills that don't quite fit into the hobbyist "How Tos" section, but don't really fit anywhere else either. Some of these books like [[Welding]] (which was listed under the Science and Engineering categories) was a perfect fit for this new section. Many such books are in the How-Tos section, but others are strewn about through the category system.

We still have a few other books strewn around that probably belong here as well. We could use some help finding and relocating them all!

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?