Me> Wikis lower the bar for participation considerably. JS> But doesn't it also lower the bar for pranks and such--say, JS> person A adds a piece of clipart that person B doesn't like, JS> so B modifies it surreptitiously? CVS would log things like JS> that. So, a couple of things about this: * Yes, it lowers the bar for abuse, too. But experience with Wikis like Wikipedia has shown that the good tends to overwhelm the bad. If you have a community of people dedicated to the idea of the project, they can "self-police" the wiki. After all, A can always revert B's changes. Or C can, or D or E or F. I think it works because, since it's so easy to change stuff, B will get bored with abuse pretty quickly. Also, A, C, D, E, and F are more committed usually to the project, than B is to causing mayhem. * There are a number of features in the MediaWiki software that runs most of the Wikimedia projects (and Wikitravel, by the way) to track edits and quickly detect abuse. It's hard to do things "surreptitiously". * Recent changes * Page histories * User contributions lists * New pages lists * Upload, delete, protect * Most of the features that could cause permanent damage, on MediaWiki sites, are reserved for special administrator users. So, for example, most people can't delete an image, a page, or whatever. They can take out all the content, but they can't delete the marker, or the history, or whatever. There's a few pages that go over how Wikis actually can work for sharing important data. On Wikipedia, there's the replies to common objections: http://www.wikipedia.org/wiki/Wikipedia:Replies_to_common_objections On Meatball Wiki (a Wiki about how Wikis and other online communities work), there's a page on "Soft Security": http://www.usemod.com/cgi-bin/mb.pl?SoftSecurity ...and one on limiting damage: http://www.usemod.com/cgi-bin/mb.pl?LimitDamage Anyways, lots of blather about Wiki, which is probably off-topic for both sodipodi-l and wikipedia-l. Sorry to both communities for excessive cross-posts, but I think this is an interesting topic that should probly be looked into. ~ESP -- Evan Prodromou <evan(a)wikitravel.org> Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide

On Dec 8, 2003, at 16:25, Toby Bartels wrote: In MediaWiki when you upload a new file with the same name as an existing file, the old version is archived and remains accessible. It can be viewed, saved locally and reuploaded with a new name, or reverted in-place. _Deleting_ an image revision would do so permanently, but this is now a restricted admin action. SVG is an interesting case though; being XML-based it would be possible to provide SVG files in human-readable -- and even human-editable -- source form. That's something we don't currently provide for, but it would be possible to provide for a file upload form that stores data into a wiki page. OddMuse's file upload feature works like this, I believe. (http://www.oddmuse.org/) Also hypothetically a plugin- or java-based editor app could be launched directly from the page, but that's outside the scope of this stuff... -- brion vibber (brion @ pobox.com)

BH> http://www.xml.com/pub/a/2003/11/19/svgwiki.html That's about the coolest thing I've seen all week. ~ESP -- Evan Prodromou <evan(a)wikitravel.org> Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide

TB> OK, this is what I was thinking of, and it was fixed. So TB> MediaWiki should work fine for showing images to one another, TB> and for writing things about them in wiki pages. But if you TB> want to modify the images' /sources/ then you want something TB> then lets you view diffs of the sources -- which may be TB> SVGwiki or something else, depending on what kind of images TB> you use! You don't need to view diffs to modify the source files. You just need to download the files, edit them, and upload the new versions. No, it doesn't happen in the browser, but that's probably OK -- I don't think a browser-based image editor could ever have the kind of features that (say) Sodipodi has. Diffing images is kinda hard. For vector image formats it's a little easier, and for stuff like SVG it might actually be practical, but for most purposes it's _extremely_ difficult to automatically detect the "difference" between two images. I doubt it would be worth the effort. ~ESP -- Evan Prodromou <evan(a)wikitravel.org> Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide

TB> I was hoping that for SVG it would be practical and even TB> useful, and if one is using SVG images, then maybe svgwiki TB> already does this. Ah! That's possibly the source of the misunderstanding. The existing "SVGWiki" is an (all-text) wiki _about_ SVG (the standard, how to use it, etc.). http://www.protocol7.com/svg-wiki/ This (single-page) whiteboarding demonstration: http://purplewiki.blueoxen.net/cgi-bin/wiki.pl?WikiWhiteboard ...uses SVG and Wiki in a very interesting way, but it's far from an SVG-based wiki. AFAIK, there is no SVG-based wiki around. ~ESP -- Evan Prodromou <evan(a)wikitravel.org> Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide