Category Archives: Arborwiki

Michigan Wikipedians – U of Michigan student Wikipedia association

Michigan Wikipedians is a University of Michigan student association.

Michigan Wikipedians (or MWiki) is a Wikipedia student organization at the University of Michigan, Ann Arbor. The group was the first student Wikipedia club in the United States. The club is open to all students and faculty of the University of Michigan, as well as community members who are interested in Wikipedia. It meets every Monday at 8:00PM at the Language Resource Center in the basement of North Quadrangle.

I went to an organizing meeting Monday 30 September 2013, here’s a few things I saw.

Use this template to link Wikipedia articles to their ArborWiki counterparts, especially if the ArborWiki articles contain more information (including information of local interest more appropriate to ArborWiki than Wikipedia).

Combine this with the corresponding pages that link to this template and you get a short list of forward links from Wikipedia to Arborwiki. There’s a similar page of Arborwiki entries with pages in Wikipedia that completes the loop.

Meetings are every Monday on the U of Michigan campus. I’m hoping to make it there 2d Mondays – 1st and 3d Mondays are Ann Arbor City Council, and 4th Mondays are a2civictech – and hope to see you there.

Notes from my talk on Arborwiki and Localwiki at eChicago, 2013

I had the good fortune to talk about Arborwiki and Localwiki at eChicago in April 2013. Here are the notes that I took in preparation for the talk; the actual text of the talk varied from this, since I was speaking impromptu.

About Arborwiki

Who: More than a dozen core contributors over the lifespan of the project, plus many more who have made small edits to pages.

Where: Greater Ann Arbor – including Washtenaw County and the farmers who come to the Farmers Market from surrounding counties.

When: Started in September 2005 as a class project at Community High School, then moved to servers at the Ann Arbor District Library.

What: About 10,000 pages, including the most popular Birthday Deals, Volunteer Opportunities, and perennial favorite Donuts and Paczki pages.

Why: To build community information about the Ann Arbor area.

Guiding principles

Locality, not notability, is the main criterion for relevance; if it's here, then it's relevant.

Take a local point of view, not a neutral point of view; original text and personal views welcomed.

Lots of external links to reference sources.

State of the project

Arborwiki is a mature system – it has over 10,000 pages in it, and thus there's likely to be something about most things that people might look for that are relevant to the Ann Arbor area.

One advantage to maturity is that a lot of people know about the project through a popular "Birthday Deals" page, and we don't have to explain in the abstract what we're working on – that individual page gets about two hundred visits per day.

A second advantage is that we've gotten tremendous amounts of cooperation from the Ann Arbor District Library system, including help with research, links, technical support, and free hosting for this community project.

Challenges of a mature system

There's no "new wiki" smell, and we can't count on having a barn-raising strategy for people who want to document their community for the first time. Any enthusiasm has to be in the context of a lot of things that already exist.

The core of regular contributors is relatively small compared to the number of pages in the system. It would take 30+ page edits per day of existing pages just to get enough eyes on the older parts of Arborwiki just to keep each page refreshed to be less than a year since its latest edit.

There are too many short, uninformative pages with just a single bare link and no photo, no map, no template etc. One editor – and that would be me – went through a long period of emphasizing quantity over quality. Now that the quantity is there, it's time to focus on quality.

The site needs more photos and better support from photographers.

The Ypsiwiki problem

Once upon a time there was a separate Ypsiwiki which covered Ypsilanti. It was decided to merge those pages in because there was too much project overlap and not quite enough of a critical mass to keep the two systems separate. The Arborwiki name was retained, and as a result, there's resistance overall from contributors from Ypsilanti to contribute to a project that's not theirs.

What to do next

Improve the most popular pages on the site. Use Google Analytics to identify the pages that get the most traffic, and go through them page by page to ensure that they are up to date, correct, accurate, and informative.

Create new pages based on a "Page not found" report from Google Analytics, noting where people click on terms that get them to a blank or empty page.

Visit a random page in the site and make it better. Add a map, a photograph, a category, or a paragraph of information.

Learn the seasonal rhythms of the site. For example, the Paczki page gets traffic for about a week a year, but the Donuts page gets steady traffic year round.

Follow public meetings like the meetings of the Ann Arbor City Council, and tweet out links to projects or issues that are relevant agenda items.

Wish someone a happy birthday by sending them a link to the Birthday Deals page on Facebook.

Reward new contributors by recognizing them in public through Facebook or Twitter links to their new contributions.

Recognize that a Localwiki project has a natural size, and identify where you are in the process.

Pay attention to traffic patterns – popular pages, referral sites, keywords used.

If you want traffic, track the news, and befriend local media so that they are aware of the resource.

Locality vs notability




In Wikipedia, every article is measured against a broad global sense of "notability". An individual or a topic has to be notable and newsworthy enough to be included, and though the standards vary there is some global consensus to what it means. If an article doesn't meet the grade, it's subject to deletion.


On a Localwiki, every article is measured against an individual sense of "locality". An individual or topic has to be relevant to that location that is being covered. Standards vary widely, but the general feeling I get is that if you put the subject's dot on a map and the dot is too far from the center of gravity of the Localwiki, it will be rejected.

This gives curious and interesting results. It means that the closing of an otherwise un-notable buffet restaurant in a strip mall is notable enough for a Localwiki simply because it's local, but also that people making worldwide headlines don't have a place in a Localwiki (unless of course they have some particular and peculiar tie to a single location). 

I find myself wishing that more places had local wikis – the process of editing is much less demanding when you simply need to identify that something is of local interest vs. going up against the global test. And locality is still ambiguous, but not so much as to be impossible to gauge.

Apologies for Arborwiki downtime

Every so often, Arborwiki's web server gets wedged, with errors like

[Sat Oct 13 21:27:47 2012] [error] [client] Premature end of script headers: localwiki.wsgi

in the log files. I've got monitoring set up to notice when this happens, but so far this has been a stumper. Apologies for the occasional downtime.

I'm now monitoring with monit which if it's working correctly should automatically restart the server if it's wedged. Of course I can't yet force it to get wedged reliably, so this might take days to properly test. Still it does notice that it's currently working and tests it every so often to make sure that it does.

The open issue on Github is here, if you care to read the gory details.

Screen shot 2013-03-06 at 1.04.44 PM

ArborWiki is moving to a Localwiki platform; what to expect

Arborwiki is a local encyclopedia about the Ann Arbor area that anyone can edit. Up til now, it's been running on the same Mediawiki software that powers Wikipedia, but we're in the process of moving it to a new Localwiki instance.

Localwiki is wiki software designed especially for using in city wikis. It's based off of ideas learned from DavisWiki, a very successful wiki based in Davis, California. The Localwiki software is especially good at handling maps, and so it should be that much easier to map out the streets and roads of Ann Arbor and surrounding Washtenaw County.

There's now also a new Facebook group to discuss Arborwiki, which has been handy for sorting through restart visuals. I'll make sure to invite everyone who has touched the project so far to it.

In response to some questions:

The migration process has been relatively smooth so far, with about 10,000 pages moved in without much in the way of hand-editing things to patch them up. There's an importer for Mediawiki pages into Localwiki that handles a lot of the heavy lifting. We had to redesign the home page to take advantage of the new include file syntax, and there are some Mediawiki templates that I used for automatically generating links to news clippings that I'll have to reimagine. Localwiki founder Philip Neustrom has been a big help, and we're running on a Ubuntu instance that Ryan Eby at the Ann Arbor District Library spun up for us.

Not a lot of the Arborwiki pages had maps on them, so Philip wrote a little bit of custom code to make that happen more frequently by automatically recognizing some pages with addresses on them. 

Typepad on iPad, edited elsewhere

No support for rich text editing in safari, but otherwise performant. Kind of nice.

I’ll need to really learn markdown for a couple of reasons, not the least of which is that it descends from setext.

Ann Arbor

A2B3 lunch is Thursday as always.
Ann Arbor Parks did trick or treat today, Sunday, noon to 4pm on the Huron River.

Arborwiki makes a good companion as you go for errands around town.
Ann Arbor City Council elections and a millage are coming up. The Ann Arbor Chronicle has characteristically thorough coverage of the League of Women Voters forums.
Some project, not yet identified, has North Main torn up at Catherine. A second project has North Division down to a single lane. Expect delays.

No one was hurt in last week's fire on Harpst.
I'm trying a neighborhood LinkedIn group to see what kind of density I need to get enough people to make a group worthwhile; it might make sense to grab people closest first and then out by distance.

Metro Detroit

Tigers lost in the ALCS, and I’m looking forward to spring training.

Power outages from the Saturday windstorms were worst in Warren.


Occupy Chicago has had a lot of protest, via the Chicago Tribune which was on the scene.

Occupy Wall Street took over Times Square.


I am tracking steps with a pedometer again, thanks to Paul Resnick and a research group at UMSI.
Statler and Waldorf have taken over the Muppets twitter account. New movie due for Thanksgiving. Cue the Muppets.


The wind on Saturday made farmers market blustery. Squash of all sizes and varieties were there, and there’s nothing like a big old Hubbard squash to keep the corner of a table down. A farmer was doing the frost dance but said they had none at the last full moon. Traditionally, it’s said that the best way to open a Hubbard is to take an axe to it, or to throw it down into the cellar.


It’s hard to have great weird ideas when you are closing trouble tickets.
My new employer Nutshell has an office where my former employer Pure Visibility used to have it's offices.


Steve Jobs, Dennis Ritchie, Einar Steffrud.


Books moved recently include Kawabata’s, Snow Country, to be shelved on the Heikki Lunta shelf to prepare me for winter.


Pinboard now supports Gopher urls in bookmarks.


Michigan football lost to State. It was as good an excuse as any to call my aunt who went to East Lansing.


Wow, I have a lot of categories.

working on metadata – stopped in your tracks and watched until you get it right

Michael Sippey writes about Ben Hammersley writing about metadata.

The quote he pulls is

So why do everything you can to keep metadata intact? Because it’s from this information that new products can be automatically created, at a scale and rapidity that would be impossible otherwise. With every piece of metadata that you don’t throw away, you gain a factor more potential ways of slicing through your content and delivering it as a separate product, simply as a result of a database lookup.

Let me give a worked-out example of this, for starters. uses Movable Type as a publishing platform; as a part of that, we have tags for each story.  A staff of journalists tagging their stories creates a lot of tags (because you are writing about a lot of things) and a few tags with a lot of stories (because you are writing a lot of stories about those things).

Keeping a collaboratively maintained set of tags sane is work (in the same way that moderating comments is work; but that's another post).  When you are writing on a deadline, you don't have the luxury to work out every last possible reuse of your work, and so you don't tag aggressively.  When you are copy editing, you might well have a reason to use or prefer a specific tag, in part because it lets you direct readers to previous coverage on the topic in a way that's much simpler than specifically deep linking to each page.

What helps me keep some part of some of the metadata I care about within the world sane is to build links to the stories that I want to refer to from an outside source – in this case Arborwiki - and as I'm doing updates to that site use it as a sanity spot-check for coverage.  Some wiki templates help speed the process of explicit linking, and an internal category helps me figure out what fragment of the tag space I've covered.  When I see a story that isn't easy to link to from a relevant page, I go back and add the tag – not because it's useful in the abstract, but because it's relevant to one specific external instance.

In this way I think that Ben is missing one of the elements of metadata, the element that says that you never really stop working on it, and that simple repurpose through a database lookup only works when you are still actively editing the database. There's nothing worse that going to a lot of work doing an attractively formatted page that's driven by a database query against a database that you can't control, and having to answer the question why a certain piece of unwanted data is there and having someone stop you in your chair and watch over your keyboard until it's gone.

Metadata only works when you un-meta it and deal with it again as data.  The list of metadata elements that I care enough to keep updating is not just meta; it's a first class real list, one that has to be treated as a first class citizen and not just some accidental system artifact.  Sometimes the metadata you expose just makes it clear how incomplete your first pass at storytelling was and what it takes to bring it back to the level of refinement that you expect.

(tags: stopped watched; so meta it hurts; arborwiki)