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. __________________________________________________________________________ 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