Wiki specification

Primary use cases:

There are plenty of kinds of documents FreeGeek creates that could go on the wiki. Here's an attempt at a taxonomy:

• Event reporting
  • Integrated with event system via one-to-one entity relationship. Allow inline editing of notes/report-backs in the event manager.
  • Examples
    • Build Days
    • Employee Work Days
    • Recycling Run
    • Classes
    • Meeting Notes
      • Staff
      • CC
      • Retreats
• Documentation of Physical Infrastructure
• Network
• Electric
• Space
• Policy.
• Discipline
• Laptop Room
• Build
• Teardown
• Testing
• Install
• Warehouse
• Documentation: Well-maintained resource guides to policy and culture at FreeGeek.
• History: How FreeGeek Chicago came to be.
• Legal Documents: Federal 501(c)3 docs, government registrations
• How to get involved: How to become a volunteer and where to contact us.
• Orientation: Include copy of current waiver form
• Governance: Constitution, roles
• Frequently asked questions: Short answers to anything noobs might ask.
• Guide to external resources for volunteers with problems that we can't solve:
  • housing
  • mental health
  • physical health
  • food
  • childcare
  • transportation
  • Internet access
• Formal proposals

What won't it be used for:

• Highly-structured data, like:
• To-do lists (which would go better in a to-do or project management application).
• Inventory lists (which are sensitive or boring, and would do better in a private Google Doc).
• Conversations or groups, which will come later -- Google Groups, sadly, works well enough for now.

What concrete documentation needs can the wiki fix right away?:

• Getting technically proficient volunteers up to speed ("read these pages on our wiki, then you can teach orientation / run test") with fewer gaffes.
• Providing documentation of our activities. Susan Golland's Sunday reports are the precedent.
• Giving Dave Eads' old Small Teams Proposal some teeth. If people's roles are more identifiable, it will be easier for people to join in on projects.

How can content be effectively categorized?:

• A hierarchical "book" model (like Wikipedia)?
• Structured categories?
• Should categories be used for navigation or should they be de-emphasized in favor of full text search?

Proposed architecture

Event-related notes & reports

• Created inline with events
• URL based on event attributes (e.g. /wiki/events/staff-meetings/2012-02-02)
• Available to volunteer managers, staff, and admins

Policy and documentation

• Created more or less free-form, with content templates provided by
• URL based on location in hierarchy provided by Drupal "Book" module. (e.g. /wiki/resources/FAQ).
• Available to staff and admins without restriction (but hopefully with training!) and all participants with staff or admin approval using Workbench module.

Display

• What is the design of wiki pages?
• How do users know they are looking at wiki page with a history?
• They see a list of edits when they hit the History button or Tab?
• They see a list of edits in small print on the right hand side of the page.
• How do they access the history?
• make it modal (via a tab or button near the top of the page, much like it is on Wikipedia)?
• have a thin column at the right side of the page with links to previous versions of the page?
• What ideas are privileged in the design:
• the page history?
• the fact the page is editable?

Editing

• Markdownify: Use TinyMCE (or CKEditor with additional porting) as Markdown source editor, with "Markdown restricted" (basic formatting -- strong, em, links) and "Markdown Advanced" (video embedding, divs with omega theme grid classes).
• Users with access to advanced Markdownify filter also able to access a set of templates to make multi-column content editing easy.

Workflow

• Staff and administrators approve wiki pages (assuming anyone may open a conversation on the public email list or on the future conversation system).
• Can or should all wiki pages be shown, including un-approved?

Comments

• How should wiki page comments work?:
• Modal (with a tab near the top of the page that hides the content and shows comments, or vice versa). Somewhat like Wikipedia?
• At the bottom of the page, hidden by a button? (which is how they do it at Salon).

Access control and security

• What forms of access control are needed for wiki pages?:
• Comments by general volunteers should be moderated before posting?
• Or should we just dump offensive/dumb stuff after we find it?
• Should some wiki pages be private ( visible to particular groups, or only editable by particular groups)?
• Private or potentially embarassing stuff shouldn't be in the wiki. We should use other means for staff and supervolunteer private business (DropBox and Keepass, some sort of private p2p, sneakernet).
• Who can edit wiki pages?:
• Everybody, but staff gets absolute admin powers.