Strategy/Wikimedia movement/2017/Sources/Russian Wikivoyage

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search
This page contains changes which are not marked for translation.

Information[edit]

What group or community is this source coming from?

name of group Russian Wikivoyagers
virtual location (page-link) or physical location (city/state/country) voy:ru:Wikivoyage:Википроект:Стратегия
Location type (e.g. local wiki, Facebook, in-person discussion, telephone conference) local wiki
# of participants in this discussion (a rough count) 12

Summary[edit]

The summary is a group of summary sentences and associated keywords that describe the relevant topic(s). Below is an example.

The first column (after the line number) should be a single sentence. The second column should be a comma-separated list of keywords about that sentence, and so on. Taken together, all the sentences should provide an accurate summary of what was discussed with the specific community.

General comments[edit]

Strategy discussion

  • We believe that the whole approach to the strategy discussion is far from ideal, because it requires time and effort of individual volunteers and incurs significant expenses from the WMF side. Unfortunately, these huge investments do not guarantee that the opinions of individual editors are properly reflected in the final document, because the outcome of the strategy are vague statements rather than specific ideas. The case of the previous strategy makes it clear that neither specific ideas nor even references to these ideas are included in the final text, and arbitrary, typically taken out of context "quotations" are used instead. The resulting strategy is nothing but a collection of slogans that can be interpreted quite differently from what the original authors implied. We deem this format pointless. The Strategy, at least in its full (extended) version, must give enough room for describing specific ideas at length.
  • We believe that planning for 15 years is too ambitious and essentially pointless, because we can't anticipate the development of IT technologies and social relations on this time scale. 15 years ago, in 2002, online maps were non-existent, cell phone memories were in the Kb range, and mobile usage of wiki articles would be a bizarre idea. The progress over the next 15 years is likely to be equally drastic. We consider 5-7 years as the upper limit for a meaningful time frame of the Strategy. However, individual problems and ideas should be solved/implemented much faster, in order to facilitate steady development of the WMF projects.
  • We believe that the overall Strategy should be rooted in the vision of how individual projects develop. A successful Strategy is to comprise several aspects: i) development of individual projects; ii) interproject relations; iii) individual projects vs. WMF; iv) outreach.

Wikivoyage development[edit]

Line Statement (summary sentence) Keywords
1 Content creation: Wikivoyage seeks to collect current information, which is volatile and constantly changing. This distinguishes Wikivoyage from other Wikimedia projects, where updates are rare or not required at all. Wikivoyage content changes regularly, sometimes on a time scale of months and even weeks. Novel technical and conceptual solutions are needed to support this fast circulation of knowledge and keep travel information up-to-date:
  • Editors can not and should not update large amounts of factual information, such as transportation schedules or opening hours. This information is already available in open databases, including OpenStreetMap, but it cannot be used in Wikimedia projects. Retrieving the data from databases requires not only technical solutions, but also a conceptual solution that entails direct transclusions from third-party (non-Wikimedia) sites or a migration of relevant databases to Wikimedia servers (see also Maps)
  • Collaboration between different language versions is crucially important for the growth of Wikivoyage. This collaboration entails sharing information on Wikidata and requires considerable development of the Wikidata functionality (see Wikidata)
wikivoyage, local wiki, open data, reviews of readers, feedback, wikidata, maps
2 Content usage: Wikivoyage guides may be used differently from Wikipedia articles, which are almost exclusively read online. This also requires novel technical and conceptual solutions:
  • Offline version is vitally important and must be integrated with maps, such that all objects mentioned in the article are displayed on a map. Eventually, it should be possible to download an article together with its map (see Maps, integration with OSM). Even if widely used online, images should be curtailed in the offline version, which is browsed during the travel and must remain compact.
  • Print version needs to be improved. Similar to the offline version, it should not be carbon copy of online article, which the current software creates with little to no possibility of customization. Travel guides can and must be used in print, and not only online.
  • Mobile version must be fully functional and convenient to use while travelling.
  • Travellers need not only travel guides, but also tools for planning their travel. Information collected in the projects should make it to specialized applications.
  • Visual presentation of media content must be improved. It should be possible to view galleries of images and not a single image embedded into an article. Audio and video files should be seamlessly integrated, and audio versions of travel guides created.
wikivoyage, local wiki, offline-wiki, print version, data processing, аdded functionality, application, media-data
3 A dedicated Community liason for Wikivoyage is needed to ensure steady development of the project. With less than 20 language editions, even one coordinator may be sufficient, but this person must have good understanding of the project and its goals, as well as solid knowledge of technical aspects and direct connection to the developers. wikivoyage, local wiki, curator
4 Wikivoyage, as well as other WMF sister projects, is strongly dependent on advertisement and external support — from boosting its position in search engines to funding PR initiatives and facilitating interaction with leading tourist services. wikivoyage, local wiki, advertisement, support

Inter-project relations[edit]

Line Statement (summary sentence) Keywords
5 Wikipedia: Although Wikipedia remains and will remain the biggest WMF project, diversification of free knowledge, especially beyond Wikipedia (among "sister projects"), should be encouraged and supported:
  • Wikipedia is well-known around the globe, whereas very few people know, for example, that practical tourist information is to be found in Wikivoyage, free texts are stored in Wikisource, and quotes can be added to Wikiquote. WMF should increase visibility of the sister projects and improve their search engine ranking (the search engine issue is essential for Wikivoyage, which is not well visible due to the large overlap with its commercial predecessor, Wikitravel).
  • Wikipedia readers will likely never recognize that sister projects exist, unless they pay attention to very inconspicuous links in the left panel. The search engine must be improved, or even a new search engine created to facilitate comprehensive search throughout all WMF projects.
6 Commons: Wikimedia Commons developed into a stand-alone and poorly organized project, a huge jumble of images, where useful content is never to be found. Novel principles of image organization and algorithms of image search must be developed and introduced:
  • Categories should be re-organized or replaced by custom filters. It should be possible to find and sort images automatically and in any language. English proficiency should not be required. When uploads contain references to databases, such as Wikidata, all image processing must be automatic.
  • Images should be sorted by quality rating and/or by their usage in Wikimedia projects. When thousands of photos of the same object are available on Commons, it is essentially impossible to find good ones.
7 Commons: Wikimedia Commons gained reputation of a project where new users are systematically humiliated and discouraged. In contrast, local sysops do anything they want, including blatant violation of rules and friendly space policies, while being unable to run the project efficiently. In its current state, Commons can no longer be used as a common image repository, because it does not warrant safe storage of the content used in other WMF projects. All technical work on Commons should be delegated to bots. Proper communication between Commons and other Wikimedia projects must be established, such that all WMF projects, as end users of images, are informed about the situation on Commons and have their say when decisions are made.
8 Commons: Similarly to Wikidata, Wikimedia Commons should be a technical project, where local community and sysops are concerned with the structure of the project without making decisions about its content. As a shared image repository, Commons also needs qualified personnel that will hold responsibility for proper operation.
9 Wikidata: The current Wikidata interface is not helping an effective integration with other WMF projects:
  • Editors can not follow Wikidata easily — watchlists either do not show anything related to Wikidata, or show too much info making it useless. The watchlists must be tunable. Watching only changes related to a given project is vital for the vast majority of editors.
  • Full usage of the Wikidata functional requires writing Lua scripts, an advanced skill that only a handful of users have. Some projects have no such users at all. A standard, easy-to-use interface is required and should be part of MediaWiki. Using this interface, every user should be able to define a template or an infobox that retrieves information from Wikidata.
  • A reverse interface, which would import information from WMF projects to Wikidata, is needed as well.
10 Wikidata: Ideally, every entity mentioned in an article must be linked to a Wikidata item and retrieve information from there. However, such linking will never take place unless the adequate interface is created (see above).
11 Wikidata: Wikidata should support many (and many means 'hundreds of') calls from a single article without any negative effect on the page loading time and stability of the interface.
12 Wikidata: Strategically, we see the increasing integration between Wikidata and WMF projects as one of the main goals of the Wikimedia movement. Both Wikidata and individual projects need additional support in this respect. The integration can not be furthered without solving the problems related to the underpopulation of Wikidata: while it is the biggest WMF project in terms of the information stored, the number of active users is very low, and even sustainable measures against vandalism remain to be implemented.
13 Maps: The existing privacy policy mandates that maps from maps.wikimedia.org should be used in WMF projects exclusively. This has serious drawbacks: individual objects displayed on the maps and the level of detail can not be customized. In practice, Wikimedia editors can not take advantage of the OpenStreetMap data, even though OSM works under a fully compatible license, and the goals and missions of OSM are similar to WMF. A full-scale map service needs to be created, either as a new WMF project or by furthering integration with OSM.

Individual projects vs. WMF[edit]

Line Statement (summary sentence) Keywords
14 Software developers should respect the community. Every active community has full authority to decide which new features they need, and which they do not. A community approval is mandatory before any new feature is implemented, and in case of doubt or conflict, compromises should be sought for. Technical developments should be based on the community requests and not on the ideas of software developers, especially if these ideas are not approved by the community.
15 The idea of hiring Strategy coordinators should be extended to hiring (perhaps on a long-term or even permanent basis) technical coordinators, who will act as liasons between the communities and software developers. This will greatly facilitate the development and implementation of new features.
16 WMF staff should be informed about the content of individual projects and their development. Training sessions with staff members acting as regular contributors of WMF projects are highly desirable.
17 It is very naive to assume that individual editors or even individual projects have enough knowledge and resources to develop technical solutions for shared projects (Commons, Wikidata, see above) and for the general Mediawiki interface (maps, offline version, etc.) Even though the development of offline tools has been articulated already in the previous strategy, this did not lead to any practical result, except for Kiwix, which is not a WMF-owned tool. Development of the offline version should be an absolute priority, and suitable tools for saving individual pages are also desirable.
18 The WMF projects are created for readers, but access to the WMF projects may be restricted. Currently, the servers are organized in such a way that any individual project blocked by IP prevents access to all of WMF projects. Such blocks are not unexpected (and they did happen in several countries, including Russia), and WMF must be pro-active instead of waiting that the problem will be resolved by itself.
19 Quality of the content should be improved by introducing a peer review system for selected (recommended, good, and featured) articles. Peer review requires organization and financial support from the WMF side.
20 Experts should be motivated to edit WMF projects. Even if contacts to individual social groups and organizations can be taken care of by Wikimedia chapters, more general problems, such as advertising Wikipedia in the scientific community, require systematic efforts from WMF.
21 Long-term contributors are not merely 'volunteers'. They are the most important and most valuable resource of the WMF. Active editors should be acknowledged in some sensible way beyond barnstars. Editing WMF projects should be a respected activity. For example, writing several featured articles should be as important for one's reputation (outside Wikimedia) as writing a book.
22 The grant system should be improved by controlling not only the goals of the project, but also its output. The granted work can not be approved as long as the community has concerns about the outcome of this work.

Outreach[edit]

Line Statement (summary sentence) Keywords
23 Wiki Loves Monuments is an initiative to create and illustrate a database of cultural heritage. Such a database has been indeed created and already surpassed any existing analogs. Its further development should become one of the WMF priorities and receive all necessary support (also financial). We believe that developing the database of natural monuments (Wiki Loves Earth) and elaborating on other initiatives of this type, which seek to record and conserve tangible heritage (as opposed to the conservation of intangible heritage, the natural goal of all WMF projects), must be prioritized.

Summary[edit]

Summary for the discussion:

Line Statement (summary sentence) Keywords
1 We envision dedicated WMF support to sister projects (other than Wikipedia), including dedicated community liaisons. These projects require special technical solutions, which should have same priority as the requests put forward by Wikipedia. Wikivoyage urgently needs full-fledged offline support. ru-wv community - 12 users
2 Wikimedia Commons and Wikidata should provide efficient service to other Wikimedia projects. Interaction with Wikidata crucially depends on the interface improvement. In contrast, the main problem with Commons is its community, which fails to acknowledge the existence of other Wikimedia projects and their inextricable connection to Commons. Both projects suffer from the low number of active users vs. vast amount of content that needs to be managed efficiently. We also envision that a third project of this type, a crowd-sourced map server, should appear, possibly by merging with OpenStreetMap. ru-wv community - 12 users
3 Experienced and strongly motivated volunteers will remain the main Wikimedia asset for the years to come. The editor retention must be considerably improved. Editing Wikimedia projects should be seen as honorable and important achievement, also in real life. Since volunteers lack knowledge and technical resources for implementing advanced technical solutions, WMF should consider technical developments proposed by the communities as its absolute priority. ru-wv community - 12 users


Detailed notes (Optional)[edit]

If you have detailed notes in addition to the summary, you may add them here. For example, the notes may come from an in-person discussion or workshop. If your discussion happened on a wiki or other online space, you do not need to copy the detailed notes here.