Open Stack

Thanks to everyone who helped collecting wiki use cases on that etherpad.

I tried to categorize the various use cases and I think they fit in 4 
categories:

1/ Things that are already in the process of being moved to reference 
websites or documentation

That would be the main "portal" page with its links to all the other 
websites, the 'How To Contribute' stuff, the information about 
elections, release naming, User committee governance...

2/ Things that should probably be published elsewhere

Sprints, IRC channels, Mailing lists, Board meeting information, 
Successbot & Statusbot logging pages...

3/ "Cheap websites" for teams, working groups and some events

That is the bulk of the remaining use cases. The wiki makes for an easy 
and immediate way to publish information about a specific team or 
working group, including specific processes, self-service team signup, 
additional meeting information... They also work well as quick-and-basic 
websites for community-led events like the Design Summit or Ops Meetups.

4/ "Etherpad on steroids" - ephemeral slightly richer documents

...where the wiki is used for building very ephemeral documents like 
meeting agendas, newsletter drafts, sharing pictures


While I think we should continue the effort on (1) and (2), we need a 
long-term wiki-like solution for (3).

One interesting aspect of (3) is that all of the content there is 
clearly linked to a team of people. So it could easily be that team's 
duty to keep those pages limited in number and updated, reducing the 
nasty side-effects of stale pages. If the tool supports it, teams could 
use ACLs and/or have to vet the creation of new pages under their 
ownership, reducing the spam aspect. One issue with MediaWiki (compared 
to some other wikis or light publication platforms) is that it's 
essentially flat, so this "ownership" concept (which helps with keeping 
spam and staleness under control) is not really baked in.

That leaves (4), where using the wiki leads to stale pages with no real 
author or maintainer being returned in Google searches. I'd argue that 
unless the document is clearly owned by a team, permanent and maintained 
up to date, the wiki should not be used. We have etherpads, we have 
pastebins, we could add others similar tools if those are not sufficient 
as ephemeral collaborative scratchpads. If we keep that category under a 
wiki-like platform, that should at least be under some /tmp special 
category that we would clean up aggressively.


Another learning of this exercise is that while some teams definitely 
rely on the wiki, we have a finite number of cases to handle. So a rip 
and replace approach is not completely out of question, if we find a 
better tool and decide that selective content-copy is cleaner and faster 
than general cleanup + bulk migration.

For the immediate future (Newton) we'll likely focus on completing (1), 
find solutions for (2), and research potential tools for (3) and (4).

Thanks again for the feedback!

-- 
Thierry Carrez (ttx)