WikisForPublishing

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Publishing is inherently a collaborative work. Artists - the writers - create the content; editors and publishers decide what is going to be published and when; proof-readers convert what the writers have created, into something that fits the style of the publication.

This page is mainly dedicated to describing best practices for using a wiki to manage copy, that is, the editorial content, for a paper-and-ink publication, but most of the ideas are applicable to web publishing too.

Best Practices

Choose a very plain style from your wiki's ThemeGarden; your writers and proof-readers will need only the most basic of plain, clear styles to highlight the words and content and de-emphasize the wiki's layout, which won't be used in the final publication.

Because the title (or even the author) may change or may not be immediately obvious, use an arbitrary page name for the article text. DanielMacKay uses the day the article was originally submitted or proposed plus an arbitrary serial number, e.g. for the third article on November 25th, 2005, the page name is 061125-03. "I have a separate mySQL database to keep track of the metadata - author, title, word count, expected/have/proofread status, and which issue the item will be used in," says MacKay, "contact me for details if you're interested."

Write a plain-english guide for editing articles in the system (as a page, of course.) Don't mention the word "wiki" or you will frighten people. Just tell them they can click on "Edit This Page" at the bottom, make changes, and later click "Save" and that everything is saved, and that even if they accidentaly erase something, it's very easy to retrieve.

If someone submits material before deadline, mail them back with the URL of their article, and the URL of the guide and tell them they can tweak their article up until deadline.

Remind your writers and proof-readers that it is impossible to permanently mess up the text, and that there are several overlapping backup systems protecting the articles.

Actually have, and regularly test, your backup system as well as the RecentChanges system.

Use a wordcount module (in Oddmuse, "wordcount.pl") to help writers and editors meet their word count targets. It's a little piece of JS which shows how many words are in the edit window at the moment.

Life cycle of an article

Writer proposes writing something. Usually they will want to write it in their favourite word processor and send you a document. Occasionally you'll have a keener who will edit directly in the wiki.
The piece comes from the writer. The Copy Manager: (1) acknowledges the submission and thanks the writer (2) drops the document into the Copy Management wiki (3) Marks the page in a couple of ways: (i) Status: ToBeProofed (ii) a working title (iii) the author's name (written as a link to the author's page with contact information.)
Proof readers search for the ToBeProofed symbol, fix up the copy, and
The editor picks which articles are going in the magazine and where - possibly using a page named for the issue (e.g. 2006_07 for July 2006) and collects all the article IDs there.
The layout team takes the proof-read copy and lays out the magazine.

CategoryWikiPractices

WikisForPublishing

Best Practices

Life cycle of an article

Discussion