Click to return to AbbeNormalNcdd Wiki

Choosing and starting a wiki for the NationalCoalitionForDialogueAndDeliberation. Your input is welcome.

There is a mailing list for this project at the bottom of: http://www.edgateway.org/ncdd/

Current status

We've chosen WikkiTikkiTavi (PhpLanguage/MySql) to launch with, some small number of weeks from now. We're seeding now...

We're still happy to hear from coders, especially if you're interested in wikis and in the content of this one (which is also related to wiki). We intend to work to improve the inter-wiki experience generally, so in the long run we'll want to work with people who collectively know everything :). We won't be surprised if we choose a different system later - maybe something in PythonLanguage (& ZoPe?) or PeRl. Our general inclination is toward simplicity (for accessibility and other reasons -- e.g., one wiki engine was rejected for being loaded with JavaScript). We were already using MySql so that was not a big consideration.

Who we are

NationalCoalitionForDialogueAndDeliberation | CoIntelligenceInstitute | SandhiInstitute

TomAtlee recently ran across the CitizensScienceToolbox, the best compilation he'd seen yet of creative and hopeful large group practices (he maintains a list of such compilations). Even better, he's gotten their agreement to copy the information to a WikiWiki, and the NationalCoalitionForDialogueAndDeliberation's agreement to have this be part of their soon-to-be wiki. JohnAbbe, who's wanted to work on a project like this for years (see CreationMatters), has taken it on, along with getting the NCDD wiki going in general.


I've been interested in wikis for years, and even moreso the broad field of individual and small to very large group practices and processes, and also how to awaken passion and compassion. Anyone else involved who wants to introduce themselves personally, please do so. --JohnAbbe

Choosing And Developing Wiki Software

WikkiTikkiTavi had most of what we wanted. See Tavi:TaviFeatures

Clean enough code so that things can be easily fixed and extended.

prefer FreeOpenSoftware because we can work on it, and it can be shared legally, and some licenses can "enforce" sharing, making an interesting legal statement about sharing and CopyRight.

Specific features we want at startup (features that we're more willing to add ourselves are marked with ***)

The basics: easy page linking, minimally-geeky markup, human-readable URLs, BackLinks, search, RecentChanges handling of edit conflicts (when two people try to edit the same page at the same time)

*** For accessibility to people new to wiki, a comment box at the bottom of each page. WakkaWiki has this, but the comments are stored separately. I'd prefer the way it is on WebSeitz, where the comments are appended to the end of the wiki page.

Questions about the hosting service

Do we get logs? Webalyzer

Is ZoPe installed? No

Features we want as soon as possible after that

SisterSites -- WikkiTikkiTavi calls this SisterWiki? -- normally requires a cron job, we have no shell access but will hack around this by rigging the script to check and trigger the job once a day, week, whatever. See http://tavi.sourceforge.net/SisterWiki

MinorEdit? (checkbox on edit pages to keep minor changes from being logged to RecentChanges)

***RssFeeds (auto-ping to weblogs.com/blo.gs?) check

XHTML & CSS (see HyperTextMarkupLanguage?, CascadingStyleSheets) check

InterWiki links check

InterNationalization? Unicode there, but needs to be turned on?

customize edit page: add link to TextFormattingRules?, Preview button; change ""Edit this document" to Edit this page, similarly View page history; add MinorEdit? checkbox

Versioning support, with diffs (shows changes between versions), and easy restore of old page versions (e.g. editable view of old versions so that one can copy & paste the wiki markup). WikkiTikkiTavi has at least the first two

e-mail subscription to RecentChanges (we can do it with RSS/BlogLet if there's no built-in function). Subscription to particular pages by e-mail would also be nice.

vpwikispec and/or other non-HTML access support (see VoodooPad)

Add feed auto-detection in header

(in Preferences) Link to a random page

Other features that might be nice in the long run

Support for AtomFeeds

embedding FeedBoxes, as OpenWiki does (certainly doable with simple macro and JavaScript, but something more native would be nice).

bot to interact with on IRC or other InstantMessaging? systems?

Image Uploading -- without this, images can be included in nearly all wikis by simply by pasting the address of a URL that points to an image that is already on the WorldWideWeb.

Granular addressing -- the PurpleNumbers you see at the end of most paragraphs in some wikis. If anyone wants to explain why we should be more interested in this, please do so,

More than TableSyntax, a CascadingStyleSheets-related markup might be interesting

InternalTranslusion?

Design decisions

Visuals and layout

On Jan 02 the old NCDD site was removed and replaced with a temporary placeholder. Although specifics like the color of the page, the background, images, etc have not yet been decided, you can get an idea of the layout and page design of the one column format that will be used for the wiki by visiting the temporary page at http://www.thataway.org . --AndyFluke

text formatting

prefer non-HTML if we use something more comprehensible to code-averse people.

link formatting

other

Do we want to technically or socially discourage any particular name styles for pages? (e.g., CamelCase? only?) technically no, socially maybe

I would encourage CamelCase? only as it makes the WikiWords "special". See http://www.burningchrome.com:8000/~cdent/mt/archives/000210.html#nidMR --ChrisDent

I agree, and at the same time, i know there are people who hate it or are confused by it. There's no way to please everyone though.

Categories -- use CategoryThis? and CategoryThat? or go for something more automated? (WikkiTikkiTavi has some automation, and produces RecentChanges views of pages in a category -- see Tavi:CategoryDocumentation )

Culture & Legalities

ToSignOrNotToSign, RealNames?

CopyRight

What can we do to do to invite people who don't see themselves as "authorized" to write?

I like the idea of having page owners responsible for editing content with sandbox areas where all can contribute and edit. You want a system that gives control in some areas, and leaves other open. - JonathanHendler

Aha! You mean have some pages be locked they can't be edited? My thought was to start us with everything open (and of course a SandBox page where we ask people to do their messing about). For spam, security, and positive reasons as well, i plan to "live" on-line on this wiki (well, maybe not as much as on my own wiki AbbeNormal), and intend to find others who would like to do the same. Tavi:TaviFeatures has "Individual page lockdown by administrator" if we decide later we want to use it. Whaddya think? --JohnAbbe

References

Also see Wiki:WikiDesignPrinciples .