Social Documentation

A long a convoluted series of thought-trains crashed together to give me this idea for a series of sites that I am now working on. It is mostly written in a notebook, but the gist of it is something I call “social documentation”.

It derives from me taking a step back and thinking about what I actually use non-Wikipedia wikae for, and how it is used by others. There are patterns in most wikae software that I like, but as implemented I can’t fit on other patterns that I would like. While I was thinking about this I was also considering how I would write documentation for my increasingly large and diverse client base.

I have a recipe in mind: WordPress + BuddyPress + bbPress + a custom theme + some plugins.

In the past I’ve been dismissive of BuddyPress because I didn’t use those patterns, and critical of bbPress because that software didn’t work the way I expected. Both projects have matured, and my understand of custom post types and the things that can be done with themes and plugins has grown. Now I think I can work with those frameworks.

And of course I am going to make it really complicated, by running my network of networks with multiple instances of social doc sites, which will share logins but have distinct communities (if I may presume that at least one other person will join me…). So there is that. ^_^

The first site that I will (well, should) focus on will be my work support documentation. That is straightforward in that it is easy to imagine what it looks like. If you’ve ever used a site that was titled a “knowledge base”, there you have it, though I endeavor to make it less boring and more helpful than most kb sites I’ve used.

After that, though, documentation changes into something for which I use wikae: aggregate logs of role-playing game sessions, notes and tutorials for video games, deconstructions and commentary on cultural artifacts (me talking about a show I just watched), comprehensive reviews on computing devices, and food recipes. Those are all real examples of what I plan to build, each a different site using a similar format, but distinct enough to power its own groups of users.

Most ideas I have don’t have as much visual/typographical design involved, so I am not practiced in explaining it. But in time it will become clear, because I practice radical transparency, and I will also be looking for suggestions and design patterns to take.

That’s all for now. Stay tuned. ^_^

Locking down the wiki

I thought about it for a day, and decided to set the wiki to only be editable by those with a confirmed email address. The main reason is that I don’t have time to fight spam now, and this may help. It isn’t a permanent decision, though I fear that I may just leave it like that out of frustration.

Eventually I hope to find a different method for combating spam, and if I went ahead with my plans for a wikae cluster and filled it with active communities, it might work. I’ve got to think about this, but I don’t have the energy to do so now.


AbuseFilter: First edit warning

I notice that a large majority of the bots that publish articles to the wiki only post once. I bet that most of them aren’t equipped to deal with additional pages in the workflow, so I made a very simple new filter. All it does is check if an account has ever edited before:

user_editcount = 0

Then it just pops up a message that says, “Hi! I am glad you are editing the wiki. We pop up this message the first time someone edits the wiki, to throw off the spambots. But you, precious human, should just submit again and we will let ya on your way! ^_^”

So far it seems to be doing a good job so far. ^_^

Thinking in wiki

I’ve been really into wikae lately, as is apparent by how much I written about it. A wiki is a particular set of features and workflows, and it has its own mindset.

I am thinking in wiki.

This site is becoming more of a journal, where my posts are either about flash in the pan events, or part of longer thought out articulations. The frequency of posts has gone down, because I am doing more mind-mapping in other places, like text files in git repos, and in various wikae.

It has brought a few things to light for me, about how I write, and what I am trying to create. Here are a few examples:

  • Temporality – A lot of the things (most?) I blog about are not important to me after a few months. That means I have old announcement posts and tons of broken links that have no value, but I keep them to provide temporal context. I am not convinced it is that useful.
  • Anti/Social – I think blogging is very important, but it does bother me that blogs are essentially silos. This isn’t really a critique, just that instead of loading up blogs with like buttons and allowing people to leave comments with their social network credentials, it is probably more worthwhile for the majority of bloggers to assess what collaboration looks like for them.
  • Our tools are aging – The software that runs some of the most important spaces on the web, like MediaWiki and WordPress, were developed a long time ago. It is easy to find feature requests from years ago, still being pleaded for. Again, not a critique, just an observation of what popularity does to software, and how dominance affects the culture and motives of the community that supports it.

These aren’t new, obviously. It is just me glancing at the gap between two software projects/workflows (WordPress/blogging and MediaWiki/wiki). Then I think about StatusNet, and how it looks like it could be practically abandoned for other projects. In one sense, that is a bummer, and I’ve invested a lot of time in it. On the other hand, maybe it isn’t so bad for things to get torn down and built back up, especially considering the transient nature of status updates, almost all of which are unimportant to me a few days afterward.

I’ve really pushed MediaWiki hard in the last couple of months. I’ve bumped up against a lot of walls, and some of them stopped me. But overall, I am happy with the result, which is a system to collaborate with those that want to, and a relatively decent way to create bodies of useful content. I am rushing as fast as I can to configure all the extensions I think I will need, so I can eventually just focus on creating. That will be the real test.

Wikae spam

My wikae are getting spammed, so now I’ve got to step up my game. ^_^

Unfortunately, wikae get targeted for spam very easily. And despite this becoming more and more of a problem, the tools used to combat it kinda suck.

In order to minimize the inconvenience for legit folks, I made some changes to help me monitor the issue. They are: SpamBlacklist, Nuke and .

  • Extension:SimpleAntiSpam – Catches dumb bots right off the bat.
  • Extension:SpamBlacklist – Uses the Wikimedia blacklist, which is okay for now. I will customize it as I see patterns emerge.
  • Extension:Nuke – Mass page deleting. Pro-tip: Searching for pages without putting in anything will give you a list of recent content with checkboxes, which is a fast way to get a lot of spam deleted at once.
  • $wgEmailConfirmToEdit – This is the worst one, which requires an email address to edit. I am just turning this on so I can have a small respite until I have more time to look into this.

It is tough having a publicly editable wiki. While Wikipedia is awesome precisely because anyone can edit it, most other wikae have neither the resources nor the critical mass required to effectively combat spam. I have to think about whether requiring an account is going to be okay for my specific needs, or if I really do think my projects can benefit from more accessibility.

One cool thing about the wikae farm is that I only have to block an account once! Makes it a bit easier to manage. ^_^


Wikimedia Foundation’s prototyping a visual editor. Will that provide a hook for more digital literacy training?

The Wikimedia Foundation has launched a prototype of a visual editor, to be used on Wikipedia, and as part of MediaWiki. You can check it out on the VisualEditor namespace on the MediaWiki site.

This is exciting, because their effort could make editing articles easier for more people. It was really depressing when I realized that nearly everyone I know is aware of Wikipedia, but has never edited it, or seen wikitext. In an amazing example of contextual privilege, I had just assumed that everyone made little edits to Wikipedia, or had wikae on their personal sites.

I’ve been playing around with LocalWiki for a while, in part because it focuses on two areas that are useful, a WYSIWYG interface and mapping. When I found out about this project I thought that it would be great for nearly all of my clients, because they all have members that can benefit from collective knowledge, especially geo-data.

It is difficult, though, because I am generally bothered by visual editors. When I install WordPress for folks (and I host over a dozen instances for my tribe), the first thing I advise is to turn off the visual editor. I equate it to speaking well, instead of good. You will be able to share your ideas, but you won’t fully understand how it is published, which is empowering in ways that most people won’t understand until it clicks.

My goal, then, is to encourage people to use sites that have a aggregate benefit, like a wiki, while also providing training in digital literacy.

It always goes back to digital literacy. ^_^

Addendum (2012-06-23): Mark pointed me to a message that links to a test wiki where the editor uses EtherPad for collaborative editing. I’ve used the embedded EtherPad into MediaWiki for writing fiction with my peeps, so this is an interesting take on it. Further down the thread it was mentioned that someone is working on collaborative editing in the visual editor. Neat stuff!

One wiki

I am collapsing all my wikae into a single MediaWiki instance. Awesome.

I like running my own web software. Sometimes that is a problem, because if I have a bunch of ideas for a particular software project, I can obsess over the details of setting up farm instances, with robust backups and turn-key deployment. When I figure all that stuff out, it is very helpful for my work. It is how I go into this, actually. WordPress, Drupal, and a whole bunch of other things.

Being paid is helpful, because it tends to give me focus. An example is that back in 2005, I had more blogs than blog posts. Fortunately, after the “maiki blog bubble” popped, I was able to get some writing done. People exchanging cash for development tends to make me more productive. However, after a while, I feel like this is a job, instead of my paid hobby.

I am fairly certain I am obsessed with wikae, Wikipedia in particular, but the idea of wiki in general. At least once a day I wish the internet was just a big wiki. I don’t think that is a good idea, but it is actually a pretty cool way of thinking about the net, and how we use it. Anyhow, the point is that I am really into these tools.

It was a problem. My ratio of wiki articles to wiki instances was closer to 1:1 than care to admit. There was my personal public wiki, then my personal private wiki, then the ones for recipes, character sheets, tech stuff, fiction bible, and then just a whole bunch more for anything I could think of.

MediaWiki is cool software, but it doesn’t come installed in a form that is easy to use. There are literally a bunch of dead links, right out of the box. And it uses a database, which practically doubles the requirements for installing it (in the context of someone using a hosted web service). Also, there are annoying things, like how URLs are created (maiki doesn’t have capital letters in it). Since I was deploying so many wikae (which really should be the plural of wiki), I turned to DokuWiki, which I still think is much better for what I was trying to accomplish. In fact, I still recommend folks look at DokuWiki before MediaWiki, if they need something that just works.

This all changed recently. The first reason is that I am starting to actually collaborate with others a lot more, in a way that makes using a wiki helpful. Much like git, the network effect increases the value of wikae by a lot. This lead to the catalyst, which was in trying to create workflows that I knew to be possible, I was essentially recreating MediaWiki’s core functions in DokuWiki (which is part of the reason I am not as enthusiastic about Drupal anymore). And then there is Semantic MediaWiki

Since looking at alternatives for Drupal, I’ve been looking at the Semantic MediaWiki extensions. Well, I’ve been playing with them for a while, but it didn’t click until just recently. When you get to add structure to a wiki using form validation, it just adds this layer of abstraction that feels like a giant sandbox of awesome to me!

So, I gotta get into this, ne? But what about the initial issues? What about maintaining a bunch of instances of MediaWiki, isn’t that a pain?

Well, it totally is, but I was fortunate enough to get a fresh perspective on it. Over a series of discussions with Kevin, I was able to express my concerns, and answer to them. I really just needed a soundboard, but it had to be someone who was directly affected by my decisions, so they could provide feedback. Kevin and I are writing a lot of fiction these days, as well as all the other projects I have going on. Once the choice to be transparent with our process, to the point of working in public, we opened up the path I’ve decided to take.

One wiki (to rule them all [except *.Wikipedia {of course}]).

Let me point out the sandbox thing again… w00t!

Having decided that, I’ve been spending time pruning and moving over content from a variety of wikae to a single MediaWiki instance. It is a great relief, because I feel like I can actively fill in a wiki now, instead of spending time maintaining the software for all of them. We still have some meta-pages to set up before I unveil it, and I would like to do more research into account verification extensions (hesitant to use reCAPTCHA, but I know I need something). I will also be writing about how I am using git submodules and symlinks to keep the extensions set up.

If I am not blogging as much, you know where I am. ^_^

Also, I use マイキ as my login. So there is that.