Web: Almost every project and organisation has, at some stage,
bemoaned having stale data on their website, and wished there was a better
way to keep it up to date; or wished their FAQ was more complete; or
wished they had the time to HTML-ize all their know-how and get it up
there.
Well, here’s what we did in SpamAssassin to deal with this problem.
(Seeing as I’ve talked about this three times in the past month, I’ll
write it up here so I can just point at the URL next time!)
First off, we experimented with having the site checked into CVS,
FAQ-o-matic, and the Python FAQ software (which was pretty good). All
were OK, but very specific in format, using the traditional
question-answer FAQ layout — that’s good for FAQs, but not so good for a
lot of other stuff — and keeping it updated was still limited to a small
group, therefore the info got stale again.
So we moved to a Wiki. Here’s my tips for Wiki-izing your website
so that the end results are better than what went in.
Use good wiki software: unusable software will be a pain to use, and
the info will still go stale. We used
Moin Moin – http://moin.sourceforge.net/ – partly because I like
Python (it’s nearly perl! ;), it can produce RSS, and it was pretty easy
to install.
Don’t worry: people won’t vandalise it (much). It turns out that
vandalism and people throwing up crappy info isn’t a serious problem at
all. You should increase the barrier, in the following ways:
Require user accounts: set the
security policy so
that a user account must be set up before editing is possible. This
means you won’t get wiki-spammed, and also has the side effect of imposing
a pretty big barrier to casual vandals.
Send changes to a list: set all changes to be mailed to a mailing list
as diffs. This is the most important tip. If you already have a
mailing list with the knowledgeable part of the community on it, use that
list — because they’re the ones who’ll be able to recognise if erroneous
info is put up, and will be annoyed about this enough to bother fixing it.
There’s a bonus side-effect of this; even if some people didn’t like the
wiki to start with, they’ll eventually be needled into using it by
wanting to fix stuff they perceive as wrong. And then they get
sucked in ;)
Use diff for the mailed changes: Moin by default will only send out
change messages saying ‘something changed on this page!’. That’s not
good enough, unfortunately — you want to mail out what the new text looks
like, and highlight exactly where the change happened. Moin can do this
nicely, with
this patch, which adds a mail_commits_address
, where all diffs
on every page are sent, using the normal diff
mechanism.
Ensure the wiki software can revert quickly: If someone does make
a bad change, Moin supports one-click reversion of the page to
what it was beforehand. That’s great for dealing with spam, or
clueless vandalism.
Keep one or two static pages: If you’re worried about some script
kiddie thinking that defacing a wiki makes them look cool, then keep
one or two of the primary user-facing pages as static data. For example,
take a look at the link-bar at the top of
http://spamassassin.apache.org/ ; five of
the ten links are to static pages, the other five are now wiki-ized. In
particular, our front page and our downloads page are both static, but
our docs are predominantly Wiki’d.
Publicize Mozex: most techie groups will have techie users, and we
hate using browser text-boxes to edit text.
Mozex — http://mozex.mozdev.org/ — saves the day here — it’s a
godsend.
Shepherd new changes: in the early stages, you want one or two people
who tidy up changes from Wiki newbies, as they go in. They need to keep
it looking pretty, and perform Refactoring
of stuff that could be laid out better or should become multiple pages.
Eventually, others will get the hang of that (and do a much better job
than you do ;).
That’s the lot. Most of these are to, essentially, migrate aspects of your
already-existing and already-working community into this new outlet.
In our experience, it’s worked really well — our Wiki is now
the most reliable source of info about SpamAssassin, and is extensive
and up-to-date.
Indymedia cross-border takedown reaches Slashdot
Web: The slashdot story. The comments contain a massive amount of noise, but there are some highlights…
Some details of the backend; it appears Indymedia need more mirrors, and the imc-tech list and #tech channel are the best contact locations to get in touch. The comment also notes that the Mir CMS used by most IMCs generates static HTML — which is a good thing! I hereby withdraw my kvetching about server-side dynamic scripting in that case ;)
The techie who ‘had the contract with Rackspace’ comments, and provides a link to his weblog, which contains copies of the trouble tickets.
He also notes that the possible illegal posting was a newswire submission — therefore not ‘published’ per se, just uploaded in the same way an unmoderated-up slashdot comment is.
And finally — he notes that the EFF are offering to represent himself and Indymedia pro bono. Yay EFF!
This is great news. Top-secret takedowns are not a good thing, especially when they span three national borders…