Strategy/Wikimedia movement/2017/Sources/Russian Wikivoyage
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:
|
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:
|
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:
|
|
| 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:
|
|
| 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:
|
|
| 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.