Documentation Wiki


I’ve mentioned before my love of wikis as a documentation platform, and I helped start the Milwaukee Makerspace wiki and grow and maintain it over the years…

Since I started working at the BBCM Exhibits Shop last year one of the biggest challenges has been locating needed documentation. Sometimes it existed, but was difficult to find. Other times knowledge existed only in someone’s head, which isn’t the best thing for an organization.

Even though I launched the wiki late last summer, things didn’t really start to get populated until December when I got a chance to pours lots of data into it, and then Sam joined us as the Exhibit Floor Coordinator and jumped completely on-board the wiki train. We’ve added over 150 pages in the last four months, and some of them are pretty extensive.

(We’re doing a small bit of integration with our ticketing system as well. Not as much as I’d like, but there’s a few weird issues with MantisBT that make things a little difficult.)

There are still more extensive pieces of documentation that exist in other formats, things that make sense as static documents, and those are often linked from the wiki so they are easy to locate as well.

In the building of this knowledge base, I like to think of it as an easily searchable manual that multiple people can update at any time. It’s not a bunch of Word documents or PDFs on a file server, it’s a living resource, meant to be used (and updated) constantly. It should serve as a useful tool not just to the people who have access to it now, but the people who join the organization in the future. A new team member should be able to sit down on the first day and dig through the wiki to get a good overview of what we deal with. (That’s my hope anyway!)


And then there was a wiki…


I’ve long been a proponent of wikis as knowledge bases within organizations. Since I discovered WikiWikiWeb in 2000, I was struck by the power and simplicity of wikis. (This was a year before the launch of Wikipedia, and many years before most people had even heard of Wikipedia!)

The first wiki I launched for a company started small, and eventually grew into a tool the Interactive department used for crucial information used by the staff. Some people believe that keeping data locked up within their own notes—or worse, just inside their own brains—creates job security. If no one else knows how something works, you become invaluable. My argument goes the opposite way, that creating a wiki and sharing all the knowledge shows your commitment to the health and well being of an organization.

During a job interview in 2006 I mentioned how I left behind a 200+ page wiki at my previous position, and without a doubt, that was the one thing that brought up the most questions from my interviewer. (The position wasn’t right for me, but I always secretly hoped they launched an internal wiki.)

Inc Magazine has a nice article titled A Micromanager’s Guide to Trust, with this great bit:

At, Martin came up with a novel solution: He created a wiki that describes how to handle some 500 operational issues.


While I’m sometimes a bit too busy to do all the wiki maintenance I’d like to do, the Milwaukee Makerspace wiki has grown to become the operational manual for the organization. This is even more important when you realize that each year a new group of leaders is elected to the Board of Directors. And since the group is a “club” and not an “employer” people are free to leave when they want. (Meaning, there’s no firing or laying people off, but we do have to deal with people who just “disappear” sometimes.)

To me, this all goes back to the original idea of why I find/found the Internet so interesting. It’s about sharing information, openly and freely, with others. It’s about storing knowledge and having it easily retrievable. Wikis accomplish these things, and for that, I am mighty grateful.

(Oh, and my favorite wiki for the past fear years has been DokuWiki. Check if out if you need to implement a wiki for your organization.)


DokuWiki Yak Shaving


Yak Shaving is described as “any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you’re working on” or something like that.

I’m not 100% sure this would be considered yak shaving, but I’m working on something that requires random pages to be served from DokuWiki, just like the built-in function that MediaWiki has. (I used to use MediaWiki, but switched to DokuWiki, and like it much better. We also use it for the Milwaukee Makerspace wiki.)

There is a random page plugin for DokuWiki, which did not work. So I took the existing code, poked at it a bit, mainly by comparing to other plugins that did work and making simple edits, and got it working. (YMMV obviously.)

Because I’m a believer in “doing the right thing” and helping other people in their quest to not reinvent the wheel and stay DRY, I figured there was more to do…

So I emailed the original author of the plugin. I’ve not gotten an email back yet. Also, he (or she) appears to be French, and I’m a stupid American who can’t read French. (I’m not even sure why I mentioned that part.)

Anyway, I was happy that I fixed something so I figured I’d toss it on the old GitHub in case someone else was looking for a random page plugin for DokuWiki that (seems to) work.

Oh, and not content to not mention something I did, I posted the link on Google+, which was picked up by Nils Hitze who mentioned it to Andreas Gohr, who happens to be the author of DokuWiki (who I follow anyway, because he’s a RepRapper too) and he suggested I adopt the (possibly orphaned) plugin.

tl;dr → I fixed the Random Page plugin for DokuWiki. You can grab it from GitHub.

Also, this is how the f’ing Internet works!


Something Somethingday

Those crazy kids! First there was Mobile Monday, then Tag Tuesday, and there’s even Wiki Wednesdays!

But what about the rest of the week? Could we have Templating Thurday? Free Software Fridays? Wait, maybe Feed Friday? Firefox Friday? Syndication Saturday? Scripting Saturday? Search Sundays?

When will the madness end!?


Personal Wiki

About two months ago I started a wiki. No, not here, on red, the Linux box in my basement. The goal was to try to replace the ~/Notes dir on my Mac with something I could easily get to (I always have a browser running) and something that would allow for easy linking and searching. I know a directory full of text files is the unix way, but I wanted something different.

I’ve been using wiki’s for a long time, but never really set up a “Personal Wiki” just for me before.

So far it’s been a huge success with all of it’s users (me) in that I’ve added over 50 pages in two months. sure there was an initial surge in page creation, but it seems that I add new pages at least every few days, and make edits almost daily. It’s a lot of personal stuff, which people would find even less interesting that what I am writing now. (If you can believe that.)

Now as for the directory full of text files, I think wget -r mixed in with some perl and cron on my desktop machine might actually solve that issue…