Okay, you knew it had to happen ... the Needs Mike page is finally here!!

In the spirit of wikiness, maybe Mike could make this an instruction page of what he does and how he does it. We could link this to the style guide and/or best practices for the portals/pages that are genres so anyone could edit/participate. Thoughts?

[I’m all in favor of you writing something down. In large part because I think our methods are similar (SQUIRREL!), and I don’t want to have to write it down myself. Plus you’ve got the whole zen-of-localwiki-features thing going. - Gene]

What I do (and how I do it)

Wow. If the Oaklandwiki gang actually finds value in me explaining my approach, I’m happy to do so – I’d actually rather do that than post to the style guide, since everyone sees things slightly differently anyway, and I dislike presuming to advise/speak for the whole group. But I certainly can share how I tend to deal with pages. So … let’s dive in!

Note: it’s assumed that everyone reading this already knows (technically) which buttons to push for editing; the following is concerned only with logical and aesthetic decisions.

So it begins.

We all know the drill – a keyed-up person sits, staring uneasily at the “recent changes” page, twitchily hitting “refresh” every few seconds until an interesting candidate article pops up. Now pretend that poor lost soul person is me (it isn’t – I have a life … really … I swear …!). Here’s what happens next:

  • I open the article in a new tab and skim it. Note that at this stage, knowing anything about the given topic barely matters.
  • I’ll immediately check the revision history of any article I sense I might be able to improve materially. (Sometimes I’ll find I’ve already edited the page; occasionally, I’ll have created the danged thing and forgotten about it. Such are the “benefits” of offloading one’s thoughts.)
    • Often, editing cues may be taken from seeing who has worked on a page. Regular editors all have distinctive, particular idiosyncrasies.
    • Checking edit times also helps me gauge how “hot” a page is. If anyone’s likely to be working on it and/or my planned edit is substantial, it’s better to wait, since Localwiki handles merged changes rather awkwardly.

Actual Editing

OK. All that preliminary garbage is out of the way. The article looks clear. I’ve clicked “Edit”. Now, I:

  • read through the whole thing first, as though I knew nothing about its subject (this is often the case; but even when subjects may be very familiar, I try to approach articles from the perspective of one wholly ignorant of them).
  • try to identify any immediate questions clueless readers would have, then note whether (and how quickly) these are currently addressed. Ideally, questions should be answered just before they can be asked. It’s not uncommon for researchers, after hippity-hopping deep down the bunny trail, to return so eager to start writing that they forget to provide an introductory context for their findings.
  • perform various sanity checks at the same time: what is the Oakland connection? (Is there one?) Do dates add up? Does the map show the right spot? Are past events described in present tense? Etc.
  • evaluate how well the page contextifies itself. If someone came here from a Google search, how lost would they be? Or, does the way the information is presented lead naturally back to the larger issue of Oakland past, present and future? In other words, does the material “fit”?
  • evaluate how well the article answers the 5 “W”’s (“who”, “what”, “where”, “when”, “why” and “how”) about its topic.
  • gauge how much content appears to be duplicated. Redundancy in written writing should be eliminated. When a page repeats content, the duplication should be removed. This is because redundancy annoys readers. It wastes people’s time and irritates them to have to read the same things over and over. Whenever a page repeatedly mentions its subject is “located in Oakland, California” I take a deep, cleansing breath. This ain’t Piedmontwiki – it’s not Berkeleywiki – it’s Oaklandwiki and everything on here is assumed to be here (and if you’re reading this, you too ought to know where “here” is) unless otherwise specified. (It’d probably be better to note only the exceptions.)
  • check that the order makes sense. Sometimes sentences or even paragraphs may need to be moved, whether to better follow a chronology or for the sake of improved narrative flow. In a long article, section headings might need to be added for clarity; or, in a short article full of headings, some might be better consolidated.
  • Finally, I consider other miscellaneous issues that aren’t problems per se.
    • The localwiki software is notorious for inserting non-breaking spaces where none are needed or wanted. Typography-agnostic users accustomed to typewriters or plain text often approximate characters, such as fractions (1/2 instead of ½); using straight quotes; accents for quotes; quotes for primes; hyphens for dashes, and various other kludges, even though localwiki encodes its pages as UTF-8 unicode, which can handle just about anything (хорошо! … جيد!). I developed routines to fix many of these annoyances automatically.
    • Photos in articles might need cropping, dodging, burning, etc. Users also tend to upload images at maximum size, which browsers must scale on the fly. The resulting slowdowns are especially noticeable when editing pages.
    • What else might make the page easier to understand? Would adding links help?

The main idea here as always is to maximize quality by following Strunk’s dictum (“omit needless words”) to find the shortest possible way to convey the material to the reader clearly, concisely, and coherently, yet completely (preserving all its meaning).

These are just a few of the questions I try to bear in mind when evaluating articles. I like to keep a mental relevancy checklist handy because I might use it for other things.

Edit tags