Scratchpad

If you are new to Scratchpad, and want full access as a Scratchpad editor, create an account!
If you already have an account, log in and have fun!!

READ MORE

Scratchpad
Advertisement

Purpose: A site written by reformers, to document the evils of the War on Drugs and suggest options for reform.

Problems: I've already discovered that wikia want most pages to be open to all members of the public for editing. We'd need a very good backup policy for that to work. It's possible that some versions allow for differing levels of access to certain pages, a registration method together with a 'revert' option and a 'no unregistered editing' setting on critical pages could help a lot.

Another point of contention is that wikia seems to have no HTML editor. A good wiki should allow content to be edited in different forms such that new users can use the native wiki editor and advanced coders can use HTML. The reason proffered for restricting users to the wiki's own language is that allowing raw HTML is asking for browser based exploits, and any filtering system is vulnerable to someone finding holes. It is easier to write a 'white list' of allowed settings, perhaps these and these alone could be allowed as HTML (though see above about filters in general), but the solution used by most is to allow them only via wiki-specific codes.

A good wiki should:

  1. Be either cheap or free
  2. Allow editors to back it up
  3. Have some restriction on who is allowed to make final edits (with such a contentious political issue it doesn't make sense to have an open editorial policy such that any anonymous user can update live content. Still the editorial board should be open and easy to join. If content is to be embargoed or subject to editorial scrutiny before going live then it's important to have a large editorial board who make frequent visits or a dedicated editor.
  4. Be easy to find content from search engines such as Google, Yahoo, MSN. I prefer a wiki that presents information to the world as HTML - this is easier for search engines to find, one factor that would directly assist in acquisition of the necessary userbase. Ideally I'd like to be able to edit pages directly in HTML, perhaps even despite the risk of vandalism via browser exploits, naughty javascript and suchlike. Are the benefits worthy of the risks? What mechanisms could be used to protect the system from such abuse? A working discussion page might be a good start if the sysop here's serious about it all :-)
  5. Have a policy for content. Will the drug war wiki restrict itself to drug war politics? I'd like to see more discussion on alternatives to current drug policy. Given the example of wikipedia's organic growth and if there was some sort of oversight to keep the subjects relevant then the DW wiki could perhaps grow in a similar self-regulating way.
  6. Have regular editorial discussions - perhaps a mailing list? - or a forum page - so that required new content can be identified.

The wikipedia.org engine seems to have a 'discuss' option built in for each page, this provides semi-threaded discussion on any points of contention, usually leading to compromises. At least it has when I've (inserted by Dave J) stuck my oar in on the subject of nuclear powerstations.

A real-world wiki is likely to have a main editor who does most of the wiki, but, potentially, anyone on the editorial board should be able to take this role over by just doing more leg-work.

The Drug War wiki will be a political wiki. I've contributed to political web-sites and important ones often have vandals attempt to bring the site down. That's why I think a Drug War wiki needs editorial control, regular backups and backups which are independent of the provider - just in case the provider decides to pull the plug. I could be wrong about the editorial control, provided that there's no mechanism for a vandal to ruin the site.

A final point (from Dave) some sort of time limit on changes, maybe a GET variable in the URL would stop people doing what I fear I could have just done, and submitting a change hours after receiving the original and thus potentially accidentally wiping out someone else's contribution.

To Sysop, please mail me direct if you like and I'd be glad to offer any ideas I can. (Providing I spot you amongst the deluge of spam) There may be a standard way of dealing with this possible snag. I don't know but I could look into it. I'm isolated from usenet at the minute so email's the only way. [Please delete this last paragraph once read]

Advertisement