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)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
