Open Stack

On 06/02/2016 10:59 AM, Thierry Carrez wrote:
> 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.

I'm interpreting "clean up aggressively" as bulk delete via a cron job,
timing to be determined.

> 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!
>

Thanks for collecting and analyzing Thierry,
Anita.