Strikeforce:Content Strategy

• To redesign the information architecture of the SkullSpace wiki (this wiki) and design a proper content management strategy that others can use to update the wiki.
• Leader: A. Michael
• Members: A. Michael, Nate, Phoul
• Status: Initial Planning

Information Architecture

The information structures of our sites need to be constructed. What is our most important information? Why are people using our sites? What are individual elements grouped under?

The final structure we reach will be the framework that informs our content strategy. Without it, we won't be able to organize the information, which will increase the risk of lost or duplicated content.

• Main Page and intro
  • FAQ?
  • What SkullSpace is
  • Map, phone, address, etc.
• Projects
  • GitHub page
  • Cook all the Things
  • SkullBrew?
• Events
  • Hackathons
  • Standalone events
• Archives
  • Meeting Notes?
  • Old tenancy stuff
  • Random pages specific to the old space
• Information
  • Bylaws
  • Member info

Content Strategy

Content Strategy refers to the procedures followed in the creation and dispersal of new content. Without a strategy, old content will proliferate and stagnate.

How should we manage our content? We need rules by which we can add new content to our data structures, and adapt that raw content into forms suitable for different media.

Here are some of the media we use to disperse content:

• Skullspace.ca
  • Wiki
  • Calendar
• Meetup
• Flickr
• Twitter
• Facebook
• Mailing Lists
  • Many of them
• Tuesday Meetings
• Billboards/Ads at the Space
• Postings on external websites

Wiki Protocols

First Steps

When creating content from the wiki, first make sure you know where you're putting it. You might need to include information from your new page in the curated list for that category (e.g.: Strikeforces), or you might need to include a category tag at the bottom. To-Do: Make a page detailing the structure of the Wiki. It will act as both a directory and a reference of where to include new content.

Archiving sets of items under an archived page

All obsolete pages should be archived, even if there is only one page that links to it. Those pages might be linked to in later documents.

To archive a page, add the following tag to the top of it:

{{Archived}}

Categories

All categories should have a corresponding page of the same name that is not a category. This makes it easier to link to categories, because then a normal link wouldn't include the category into the page that contains the link, and it allows us to link to both categories and false sub-category curated pages (like "Archived Events") in the same way.

Handling subcategories of categorized items

The easiest way to manage individual items is to put them in subsections of their category parent page. For example, "Cook All the Things" contains each recipe under different headings for the courses, rather than just listing the names of all the recipes.

This becomes harder when things need to be included in more and more subcategories. In that case, adding each of them as categories will automatically add it to those category pages, so they're all easy to find.

What's the best default? Will members always include their new entry into the appropriate list on the parent category? Or can we expect them to know the differences between all subcategories and apply all the right ones?

Events

A wiki page might be for one event, or could be about a recurring event.

For a single event, either the title should include the ISO 8601 date at the beginning, or the page should include a tag at its bottom which rewrites how it's categorized in each category. Following this example with your date in place:

{{Date|1999-12-31}}

This would sort it under the heading "*" with proper date sorting.

Time-based items should be separated from the informational items. Unfinished time-based items like events should belong to a category that can routinely be sorted through to archive items as they expire.

Projects

Informational items and projects should have owners. When a member leaves, any projects and information led by that member must be reassigned or archived.

An audit should be performed every so often (twice a year?) to determine whether or not the active projects are up to date. If they are not, they should be brought up at the next meeting and either revived, reassigned, or archived.

Archives

The link to the archives should be in a prominent place on the front page. Create an Archives page to curate examples of archived pages and tell stories around them, with a generic link to the Category:Archives for a complete list.

Archived articles become our history. For improved context, archived files should have pertinent future-tense or present-tense words changed to past-tense. (This isn't a requirement.)

If a page to be archived is incomplete (usually because it's missing its date), place the following template at its top with the reason inserted into the placeholder:

{{Unfinished | Text=Additional information goes here.}}

List Items

Lists of items like the recipes should all fall under a parent topic like Cook All The Things, which falls under a main category like Projects. We need clear locations for the top-level items. The really important ones, like Projects, should be front and center. If there are a whole lot of subcategories that can fall under one or two main categories, put them there and give those main categories a good spot on the front page.

Updates

Updates either should be immediately archived or should be put in dated threads in dated categories for pseudo-archiving. For example, the meeting minutes have the dates in the title, and a large list of them can easily be browsed.

Other Questions

Curated pages and category pages

In some cases, a full description is not necessary. The events, for example, only need a curated selection of event descriptions in the main body, with a link to the full category. Does it matter whether we redirect from a given page to its category, and include all content there? If we do, we can post what we want on that page and there'll automatically be a list of all category items at the bottom.

1. We have the standalone Events page, which looks nice, and links to Category:Events, which is fairly bare.
2. We create the Events page, but redirect it to Category:Events, which will contain both the curated content and the list of all events. It's harder to link to categories (the page becomes part of that category), so this way lets us easily link to categories, too.

So far, the second one sounds best.