Tag results
The Future Melbourne wiki - "the city plan that anyone can edit"
Future Melbourne is a wiki I’ve been aware of for a few months now. The City of Melbourne decided to put their city plan for 2020 (replacing the one for 2010) into a publicly editable wiki for a month, as part of the public consultation process. There is a kind of summary of the project on the Future Melbourne blog, declaring it a success. There is also a short video with Mark Elliot whose company CollabForge helped the city customise and use the wiki (the wiki engine was Twiki).
I think Future Melbourne is an awesome initiative, but considering it garnered just 200 edits, it barely scratched the surface of what is possible with government-public consulting.
There seems to be an unstated assumption that people now generally understand what wikis are and how they work. I have not seen any study or survey with this kind of conclusion and until I see that, I would work off the opposite assumption. That is, I would have multiple free and highly publicised “what is a wiki? what is our wiki for? how can you use our wiki?” hands-on information sessions. To just say “come and edit our wiki” is not going to get the best response, because it assumes that the technology is familiar enough to be invisible — which it is not, even for enthusiasts. Either that or it is making the mistake of focusing on the tool instead of what can be achieved by using it (e.g. “contribute to (y)our city plan”).
The second thing which I think was not much explored was: what does an ideal wiki page look like when you are editing a city plan? Wikipedia works in terms of having one page per topic because of the NPOV (neutral point of view) policy. But asking people to form a NPOV city plan doesn’t make any sense. People can contribute by sharing their vision for what the city could be. But no individuals’ vision is more right or wrong than anyone else’s. For me, I would like Melbourne to be a cyclists’ paradise. Others may prefer a pedestrian’s paradise and still others may want a car-centric highway heaven. When we are all editing the transport policy page together, what rules can we or should we use to find a version of the page that is acceptable to all of us? Is that even possible? Or could there be multiple pages representing our individual wishes? How are they then to be understood in relation to each other and the rest of the plan? Which one is canonical?
I tend to think that neglecting this “ground rule” is not a good idea, and that with this kind of document a more simple “comment” or feedback approach may be better. You could use this in combination with allowing people to suggest new or expanded policies/goals.
I think this topic basically didn’t arise because of the low participation, but it is really something I would want to come to grips with before launching a wiki project with greater participation.
Another thing that makes me think a wiki is perhaps not the perfect tool for this is the short editing timeframe – one month. Wikis show their strengths over months and years and probably decades. For one thing the longer time scale allows for a community to develop. While in Future Melbourne’s case they had staff monitoring and responding to edits, and that’s good, certainly better than nothing, and probably the best you could hope for in a short time frame — it’s still something that reflects a top-down power structure. The reins may have been loosened a bit but they’re still ready to be snatched back up should things go awry. It wouldn’t hold a candle to a truly community-run/powered/managed wiki. You have to be in charge, have some power, to really own something, and it’s then that you become invested, engaged. It’s then that you care.
The City of Melbourne has made some bold steps but I think there are many more ahead. Once they start to be taken the relationship between government and the public will become very vibrant and interesting. And not a moment too soon, eh?
A FLOSS Manual: How to contribute to Wikimedia Commons
“Oh Brianna,” you may ask, “What is that most interesting tome you’re reading?” Why, I’m so glad you did. It’s a Lulu-printed version of a short manual I wrote called How to contribute to Wikimedia Commons.
So, I spent the week before Wikimania in France. The purpose was to hang out at the FLOSS Manuals Inkscape documentation booksprint and also to hang out with my French friend (un-wiki related). As you may have guessed I am a big Inkscape fan. (Inkscape is the premier open source software for creating and editing vector graphics, i.e. SVGs.) But I definitely don’t know enough to really help out with writing documentation. I would be too busy reading it. So I decided to write some documentation to help people who might be familiar with Inkscape, i.e. accomplished or semi-accomplished illustrators and artists, but new to the complex and confusing world of Wikimedia. That is the aim of my manual, to be a self-contained introduction to contributing to Wikimedia Commons, without information overload.
So you can read the manual online at http://en.flossmanuals.net/WikimediaCommons/. You can also check out the editor’s view at http://en.flossmanuals.net/bin/view/WikimediaCommons/WebHome. FLOSS Manuals uses a highly customised version of Twiki — yes, a wiki. The most immediate difference between Twiki/FM and MediaWiki is that Twiki/FM uses a WYSIWYG interface that converts directly to HTML (which you can also edit directly if you really want) — no “wiki markup” intermediary. I thought it would bug me (Wordpress’ annoys me immensely), but I soon got used to it and didn’t find it slowing me down at all.
Twiki/FM is great for planned-ahead books with a small number of authors where the bulk of content is written over a known time period, but MediaWiki is definitely better suited to laissez-faire, largely unstructured book development by an unknown number of authors over an essentially unbounded time frame. That’s not to say that there aren’t a significant number of improvements that MediaWiki requires to really meet the needs of book authors and their enablers.
I also feel that Twiki/FM is a better choice if you want your manual to have an offline life, whereas MediaWiki is much better if you intend it to stay all linked-up on the web. The killer feature here for Twiki/FM is Objavi. It’s a wiki-to-pdf converter that uses CSS for styling and most importantly, actually looks great.
Basically double-handling is the killer. If you are doing speedy wiki-based authoring the last thing you want to do is have to edit a version specifically for print. It’s intolerable.
MediaWiki/Wikimedia is supposed to be getting its own whiz-bang PDF generator, via a partnership with Pediapress. So far it’s only enabled on a test wiki. The interface for creating a new “collection” (for Wikibooks, this will be usually equal to a book) is really awkward. But if admins get the hang of it and create nice PDFs for everyone else that will be nice. OTOH that won’t work on Wikipedia at all, where people will most likely creating their own custom grab-bags of articles. And unlike Objavi there is no way to specify print-specific style at all. Having said that, I just looked through a sample pdf (log in and click “Load collection” on the left, then follow the prompts) and it is quite impressive.
The issue that both Objavi and Pediapress seem to struggle with is that of images — their size and placement. Web-appropriate proportions just don’t suit normal portrait-orientation books. Someone should do a PhD on figuring out a good algorithm to convert them automatically. :)
Anyway! Back to my manual. It’s dual licensed under the GPL and GFDL, as GPL is the license ordinarily used by FLOSS Manuals, and I asked for GFDL licensing for obvious reasons. My hope is that chapters and similar groups will keep a copy to share with people who prefer book documentation.
I haven’t yet sorted out a pricing thing on Lulu, but I was hoping that it could be sold for cost + 2 euro (1 for FLOSS Manuals, 1 for the Wikimedia Foundation).
I also hope to see simple Wikipedia introductory manuals developed. English and Spanish ones in time for Wikimania would be nice!
By the way, this took five freaking weeks for Lulu to ship, so excuse me if I am overly excited. :)
