Re: [openstack-dev] Collecting our wiki use cases
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
Re: [openstack-dev] Collecting our wiki use cases
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
[openstack-dev] Collecting our wiki use cases
(posting as separate thread upon request) Hi everyone, At the beginning of OpenStack we have been using wiki.openstack.org as our default community lightweight information publication platform. There were/are lots of things in there, reference information that a couple people struggled to keep up to date (and non-vandalized), old pages referencing processes or projects long gone, meeting agendas and minutes, etc. That created a mix of up-to-date reference information and completely outdated random information that is confusing to use (especially for newcomers to our community) and that Google search indiscriminately provides links to. Over the last two years, various groups have worked to push reference information out of the wiki, to proper documentation guides (like the infra guide or the project team guide) or to peer-reviewed specific reference websites (like security.o.o or releases.o.o). These efforts to move reference content to other tools and websites where appropriate will continue. There are still a lot of use cases for which the wiki is a good solution, though, and it is likely that we'll need a lightweight publication platform like a wiki to cover those use cases indefinitely. Since it's difficult to have a complete view of what the wiki is currently used for, I'd like to collect information from current wiki users, to make sure we have the complete picture of wiki use cases as we discuss adding new tools to our toolbelt. So, if you use the wiki as part of your OpenStack work, make sure to check if your use case is mentioned on the etherpad at: https://etherpad.openstack.org/p/wiki-use-cases If not, please add your use case, together with the URL of such a wiki page to that etherpad. Thanks in advance, -- 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
