龙8国际老虎机娱乐 “FAQ”的版本间差异

来自广财百科
跳到导航 跳到搜索
（页面内容被替换为“==数据库== <!--T:1--> ===What are the differences between MediaWiki, Wikimedia, Wikipedia and wiki?=== <!--T:2--> <!--T:3--> This is a common question; please se…”）
标签：替换
第1行： 第1行：
This document is a '''feature map''' or taxonomy of possible additions and changes to the MediaWiki software and to other parts of Wikimedia's technical infrastructure, validating potential features against Wikimedia's [[strategy:Wikimedia Movement Strategic Plan Summary|strategic plan]]. It is very much a living document, but if you make additions or changes, please remember to update the map itself, or at least log them in the [[/Parking lot|parking lot]]. If you're interested in WMF's current product priorities, please see the full [[strategy:Product Whitepaper|Product Whitepaper]].
==数据库== <!--T:1-->
===What are the differences between MediaWiki, Wikimedia, Wikipedia and wiki?=== <!--T:2-->


The strategic impact assessment is driven by the Wikimedia Foundation and the Wikimedia community:
<!--T:3-->
This is a common question; please see for a detailed answer.
* Impact on '''Reach''' means increase in the number of people perusing Wikimedia projects.
* Impact on '''Participation''' means increase in the number of people actively contributing content of value to our audience.
* Impact on '''Quality''' means increase in measurable quality of existing content, or generation of quality content by the existing community.
* Impact on '''Innovation''' means increased likelihood that the movement (in the largest sense) will develop tools that advance strategic priorities.
* Impact on '''Diversity''' means increased likelihood that groups currently underrepresented in the Wikimedia movement will join it.
'''[[Media:Wikimedia Feature Map.png|View full-size version of the feature map]] - [https://tools.wmflabs.org/zoomviewer/index.php?f=Wikimedia_Feature_Map.jpg&flash=no  View in zoomviewer]'''
__TOC__
[[File:Wikimedia Feature Map.png|900px|center]]
{| class="y2x3zmnjy29t wikitable"
|-
! Product area !! Subcategory !! Brief description !! Strategic impact hypothesis
|-
|colspan="4" align="center" style="font-style:italic;background:#eaffea;"|
===Reading: Features that enhance the reader experience===
|-
| '''A.''' Reading
||
===='''1.''' Content presentation ====
||
Features that aid consumption, either by improving the presentation of e.g. a Wikipedia article for the purpose of readability, or by surfacing supporting content (images, videos, spoken versions) with better affordances and improved flow.
Examples:
* [[commons:User:Dschwen/Slideshow|Slideshow gadget on Wikimedia Commons]]
* [[commons:MediaWiki_talk:Gadget-ZoomViewer.js|Zoomviewer gadget on Wikimedia Commons]]
* [http://www.sophiestication.com/articles/ Articles Wikipedia iOS app], [http://itunes.apple.com/us/app/id384224429?mt=8 Discover Wikipedia iOS app]
* [http://qwiki.com Qwiki], a transformation of content from Wikipedia and other sources into spoken presentations
||
# We can increase the frequency and duration of site visits by current users and the number of new users discovering and visiting WMF sites, by providing faster access to information, increasing reader satisfaction, and facilitating serendipitous discovery of content. <br/> '''Strategic priority: Reach'''
# Our potential for converting readers to active participants increases by engaging new readers, or by deepening engagement with existing readers. <br/> '''Strategic priority: Participation''' [low efficiency]
|-
| '''A.''' Reading
||
===='''2.''' Search====
||
Features that improve search user experience, relevance of search results to a given query, search across different content sources, search performance, multilingual discovery, etc.
Examples:
* [[usability:What's New|Search enhancements rolled out as part of the 2010 usability update]]
||
# As A.1.1.
# As A.1.2.
# Making content findable that's not in a language the reader speaks may in particular surface multimedia content that's otherwise "dark", and thereby dramatically expand the number of people who can be served using these resources. <br/> '''Strategic priority: Reach'''
|-
| '''A.''' Reading
||
===='''3.''' Customization/Discovery====
||
Features that suggest useful content based on user behavior, or that surface related and relevant content (related articles, sister project content, etc.), or that hide content that's not desired (e.g. graphic depictions of violence)
Examples:
* The [[w:Help:Books|book tool]] organizes related articles in collections, and makes suggestions for relationships.
||
# As A.1.1.
# As A.1.2.
# User-controlled viewing options may increase the degree of comfort of individual readers by reducing exposure e.g. to undesired images, and thereby increase their likelihood to peruse our projects. On a macro-level, the existence of such options may help mitigate concerns about the inclusion of such content, and thereby improve our ability to increase reach and participation. <br/> '''Strategic priorities: Reach, Participation'''
|-
| '''A.''' Reading
||
===='''4.''' Export====
||
Features, technologies and applications that make Wikimedia content available in formats suitable for re-use, either in ways directly relevant to the reader (e.g. PDF or OpenDocument download) or in indirect ways that can be built upon by others (e.g. downloadable XML files).
Examples:
* The [[w:Help:Books|book tool]] allows purchase of books from print-on-demand service providers and experimental export in OpenDocument format.
* [https://openzim.org/Main_Page OpenZIM, an efficient offline storage format for wiki content]
* [https://kiwix.org/ Kiwix], an open source offline reader app
* [https://dumps.wikimedia.org/ Wikimedia database downloads] and [[w:Special:Export|XML export]]
||
# As of early 2011, about five billion people in the world do not have access to the Internet, and these are grossly over-represented in developing countries. While over 50% of the developed world's population is online, only 17% of the population in transition economies are online, and only 15% are in developing countries. Leveraging a portfolio of offline delivery mechanisms may enable us to serve hundreds of millions of people who otherwise do not have access to Wikimedia content. <br/> '''Strategic priority: Reach'''
# When combined with quality assurance technologies, offline exports may provide a safe and acceptable delivery method of free educational content to the educational sector world-wide, enabling us to deliver Wikimedia content in a setting where it would otherwise not be used. Delivery of content in editable formats like OpenDocument may also increase adoption by educators due to increased customizability for an educational setting.  <br/> '''Strategic priority: Reach'''
|-
| '''A.''' Reading
||
===='''5.''' Navigation====
||
Features that improve basic site navigation, increasing the discoverability and usability of highly desirable site features (e.g. improving to category access and navigation, surfacing frequently used navigation links more visibly, making navigation labels more obvious).
Examples:
* The [[Extension:CategoryTree|CategoryTree]] extension in use on Wikimedia projects eases traversing categories
* In the [[usability:Main Page|Usability Initiative]], click-tracking was used to assess and improve sidebar and toolbar link usage
||
# As A.1.1.
# As A.1.2.
|-
| '''A.''' Reading
||
===='''6.''' Mobile/tablet device experience====
||
Features and technologies that leverage device-specific capabilities (e.g. geo-location of relevant articles via GPS, touch navigation, augmented reality), and which format content in device-appropriate ways (e.g. smaller screens), to improve the reader experience, especially with regard to the large categories of smartphone and tablet usage. This category of functionality needs to be understood in close connection with participatory functionality targeting this category of devices.
Examples:
* [http://en.m.wikipedia.org/ The smartphone-optimized mobile gateway]
* [http://itunes.apple.com/app/wikipedia-mobile/id324715238?mt=8 Official Wikipedia iPhone app]
* [http://mobiled.uiah.fi/ MobilED, using text-to-speech to send audio versions of articles to phones]
* Various Wikipedia apps for mobile & tablets
||
# As A.1.1.
# As A.1.2, provided that participatory capabilities are present.
# For hundreds of millions of users, a number that's rapidly growing, mobile devices are the ''only'' mechanisms by which they access the Internet. Providing a heavily optimized mobile experience is therefore essential to reach those individuals at all. <br/>'''Strategic priorities: Reach'''
|-
|colspan="4" align="center" style="font-style:italic;background:#eaffea;"|
===Reader Conversion: Features that drive a greater percentage of readers to contribute===
|-
| '''B.''' Reader Conversion
||
===='''1.''' Opportunity discovery ====
||
Features that highlight ways for the reader to improve a Wikimedia project, ideally relevant to their actual usage and likely ability to help. This may be achieved by first promoting affiliation ("Join WikiProject Medicine!") before inviting participation.
Examples:
* Classic MediaWiki features like, [[w:Wikipedia:Red links|red links]] and templates like [[w:Template:Stub|"This article is a stub. You can help Wikipedia by expanding it."]]
* [[w:Wikipedia:Contribution Team/Welcome2|2011 experimental Wikipedia banner campaign which invited people to edit]]
* [[w:Wikipedia:Image placeholders|Placeholder images]] were used in English Wikipedia for a while to invite image uploads.
||
# Especially in mature Wikipedia language editions, opportunities for improvement are far from obvious. According to the 2008 survey of Wikipedia readers and contributors, "the primary reason non-contributors would consider contributing is if they 'knew there were specific topic areas that needed [their] help' (34-41%)" [http://wikipediasurvey.org/docs/Wikipedia_NonContributors_15March2010-FINAL.pdf]. Highlighting opportunities to help, either directly or through community affiliation, may significantly boost the number of readers who decide to take the plunge and to make an edit, upload an image, etc. <br/>'''Strategic priority: Participation'''
|-
| '''B.''' Reader Conversion
||
===='''2.''' Entry vectors====
||
Features that allow lightweight participation and are designed to transition users to deeper engagement. This may include persuading readers to join an ''off-wiki'' event like a meetup, workshop or conference.
Examples:
* Image uploads from smartphones, in combination with a feature-set like [[strategy:Proposal:Media review|media review]], may provide a simple feel-good way to help Wikimedia projects, which could be leveraged for further engagement.
* [[w:Wikipedia:HotCat|HotCat]] and [[commons:Help:Gadget-ImageAnnotator|the image annotation gadget]] are examples of lightweight editing mechanisms, but both are restricted to registered users to minimize noise.
||
# Given both the perceived magnitude and complexity of the task, and the concerns associated with the very ''concept'' of editing a wiki, lightweight participation mechanisms may offer a mechanism to engage a larger number of readers than the "Edit" button alone. If a significant percentage of those engaged readers are willing to then take an incrementally larger step (make an account, fix a typo, etc.), we may be able to successfully create a new funnel for converting readers into contributors.<br/>'''Strategic priority: Participation'''
|-
|colspan="4" align="center" style="font-style:italic;background:#eaffea;"|
===New Editor Support: Features that increase retention of new contributors===
|-
| '''C.''' New Editor Support
||
===='''1.''' Tutorials====
||
Features and technologies that relate to surfacing friendly and easy-to-understand information in key locations. This may include interactive tutorials, tours, etc., but generally is likely to only be lightly technology-dependent, with the exception of analytics to compare the effectiveness of different approaches.
Examples:
* The [[commons:Special:UploadWizard|Upload Wizard]], designed through the [[m:Multimedia usability project report|multimedia usability project]], shows a [[m:Licensing tutorial|licensing tutorial]] (an internationalized SVG comic strip) before beginning the upload process. Some information is also moved into balloon tips.
* Many tutorials are being developed and indexed in the [[outreach:Bookshelf|public outreach bookshelf]], and the [[outreach:Account Creation Improvement Project|Account Creation Improvement Project]] wants to experiment with the integration of such tutorials into the account creation process.
* The [[w:Wikipedia:Tutorial|tutorial]] on the English Wikipedia is a step-by-step instruction to editing developed by the community, and the [http://wikieducator.org/Wikieducator_tutorial Wikieducator tutorials] are a more pedagogically structured approach.
* The [[w:User:Eloquence/Tour 01|tour mock-up]] is an example of what a guided tour could look like.
||
# Even if all technology-based usability issues could be fully resolved, Wikimedia projects trend towards increasing complexity as quality standards rise and community norms evolve. Details of procedures and conventions can be learned over time, but explaining key concepts early and well may reduce the friction that new editors experience when contributing, and thereby increase their likelihood to stay. <br/>'''Strategic priority: Participation'''
|-
| '''C.''' New Editor Support
||
===='''2.''' Mentoring tools====
||
Features that relate to connecting new users with experienced mentors who can respond synchronously or asynchronously to a new user's questions, expressed intentions and actions, and features that help manage and evaluate mentors/mentee relationships.
Examples:
* The [[w:de:Wikipedia:Mentorenprogramm|mentoring program]] in the German Wikipedia is one of the largest scale community efforts to help new users. It is supported by a [http://toolserver.org/~dewpmp/index.php?action=mentees toolserver-powered mentor/mentee tracker] and an IRC chat room.
* There are similar programs in other languages (e.g. [[w:Wikipedia:Adopt-a-user|Adopt-a-user]] in the English Wikipedia).
||
# Connecting users early on with at least one constructive, experienced Wikimedia contributor who dedicates a certain amount of time to supporting their acculturation may mitigate other negative social experiences, provide information about practices and principles in response to actual user behavior, and help explain to the contributor that Wikimedia is a ''community'' of shared values and not a ''system'' that dislikes them. <br/>'''Strategic priority: Participation'''
# To the extent that mentoring systems give new contributors choices about whose help they would like to receive, they may help new contributors find someone who they identify with (age, gender, ethnicity, etc.) or can communicate with easily, supporting the acculturation of new contributors who do not represent majority characteristics of the Wikimedia community. <br/>'''Strategic priority: Diversity'''
|-
| '''C.''' New Editor Support
||
===='''3.''' Interaction with advanced users====
||
Features that systematically ease friction between new and experienced users.
Examples:
* The [[w:User:EpochFail/NICE|NICE user script]] by researcher Aaron Halfaker "is designed to make communication easier at a very crucial interaction point between editors, the revert" by making it easier to provide explanations when reverting, and showing warnings about newbie-biting. The goal is to determine what types of interventions lead to increased newbie retention.
* Improved profiles like the user page component of [[Extension:SocialProfile|SocialProfile]] may help experienced users better distinguish between good faith and bad faith editors, especially if profile creation is more strongly encouraged.
||
# We know that revert ratios towards new users have trended upward for many years, and there is strong survey data to suggest that problematic interactions with advanced users are contributing to a decrease in new editor retention. While not all of the causes of such problematic interactions can be rectified, relatively simple interventions could have a large payoff in terms of increasing retention rates of new users. <br/>'''Strategic priority: Participation'''
|-
| '''C.''' New Editor Support
||
===='''4.''' Training wheels====
||
Features that help new users perform complex tasks using methods that may or may not be suitable for advanced users.
Examples:
* The toolbar that is part of the [[Extension:WikiEditor|WikiEditor]] extension (in production use on WMF wikis) includes pop-up tools for adding links, formatting text, inserting tables, etc., as well as a built-in cheatsheet. Some of these features are of limited interest to experienced editors but potentially helpful to newbies.
* WikiHow has forms-based guided editing processes for [http://www.wikihow.com/Special:CreatePage page creation] and [http://www.wikihow.com/index.php?title=Take-Care-of-a-Praying-Mantis&action=edit page editing] which can be overridden by advanced users.
||
# Wikis are complex systems, and even with significantly improved editing interfaces, new users have a lot of complexity to overcome. "Training wheels" may support that process and decrease fall-out early in the new editor acculturation process. <br/>'''Strategic priority: Participation'''
|-
|colspan="4" align="center" style="font-style:italic;background:#ffeaea;"|
===Editing/Contribution: Features that make it possible or easier to contribute content===
|-
| '''D.''' Editing/Contribution
||
===='''1.''' Rich-text editor====
||
Technology to deprecate wiki syntax as the primary input method used to create content in Wikimedia projects, and to instead make it possible to compose complex pages using a rich-text editor which also intuitively represents templates, magic-words and other wiki-specific paradigms.
Examples:
* Magnus Manske's [[WYSIFTW]] experiment
||
# Wiki markup was a good idea in 1995. Providing intuitive access to all core editing capabilities by leveraging modern web browser technologies will dramatically lower the barriers to participation for non-geeks, which is a necessary (but probably not sufficient) precondition for converting a significantly larger percentage of readers into active contributors. <br/>'''Strategic priority: Participation'''
# Even experienced editors sometimes struggle with elements of wiki markup (e.g. tables, citations), and an optimized rich-text interface is likely to significantly increase their productivity.<br/>'''Strategic priority: Quality'''
|-
| '''D.''' Editing/Contribution
||
===='''2.''' Block-level text editing====
||
Technology to make it possible to make quick in-place modifications to individual sub-components or sections of a page, e.g. sentences, paragraphs, sections, templates, categories, captions, citations.
Examples:
* [[w:de:Wikipedia:Skin#ASM|User script developed for the German Wikipedia that allows in-place section editing]]
||
# By increasing the number of entry vectors for changes, and minimizing the total transaction cost of making a change, we can significantly increase the number of constructive edits, and potentially convert more people to become active contributors. <br/>'''Strategic priority: Participation'''
# Better tools for quick changes are likely to significantly increase the productivity of experienced editors.<br/>'''Strategic priority: Quality'''
''Risks:''
* Experiments with simple contribution mechanisms, such as image annotations, have suffered from a low signal/noise ratio when made available to unregistered editors. It may be necessary to balance such contribution mechanisms with moderation tools, or even to introduce deliberate barriers before first-time use.
|-
| '''D.''' Editing/Contribution
||
===='''3.''' Improved code editor====
||
Technology to deal with wiki markup and other code more effectively (e.g. syntax highlighting, code folding, improved preview workflow).
Examples:
* [[w:User:Cacycle/wikEd|wikEd]], "a full-featured Wikipedia-integrated advanced text editor for regular to advanced wiki users", which supports reference and template folding.
* [[usability:Sandbox|Improvements by the usability initiative]], including some which aren't staged, such as template folding, navigation inside the editor, and improved preview/save workflow.
||
# It's easier to improve the standard interface than to implement, for example, a rich-text editor, and some improvements may significantly impact the experience of new users, or the productivity of experienced editors. Some of the core concepts employed when making such improvements may also be applicable to a rich-text editing interface (e.g. collapsing templates and making them editable via forms).<br/>'''Strategic priority: Participation, Quality'''
# To the extent that actual code is written in wikis (e.g. LaTeX, template code, various other extensions like EasyTimeline), a dedicated code editor may help experienced editors be more productive. <br/>'''Strategic priority: Quality'''
|-
| '''D.''' Editing/Contribution
||
===='''4.''' Real-time editing====
||
Technology that enables multiple editors to work on the same document synchronously, and to track changes irrespective of creating an explicit revision (e.g. near-atomic change history that can be explored through a time-slider).
Examples:
* [http://etherpad.org/  Etherpad] is an open source real-time collaborative web editor (see also [[strategy:Proposal:Etherpad-based editing]]).
* [http://docs.google.com/ Google Docs] allows real-time collaborative editing, including [http://googledocs.blogspot.com/2010/11/editing-your-google-docs-on-go.html from mobile devices].
* [http://wiki.apache.org/incubator/WaveProposal Apache Wave] is the open source release of Google Wave ([http://demo.wave-in-a-box.org/ demo]). It allows federated real-time collaboration and messaging.
||
# Enabling synchronous editing could increase productivity by essentially eliminating [[w:Help:Edit conflict|edit conflicts]], especially on pages that are being rapidly revised (current events, news stories, etc.). It could also enable completely new use scenarios that are currently impossible (e.g. real-time editing sprints), have positive effects on newbie/advanced user interaction, and generally make editing a more enjoyable and addictive experience. <br/>'''Strategic priorities: Participation, Quality'''
|-
| '''D.''' Editing/Contribution
||
===='''5.''' Multimedia====
||
Technology that makes it easier to upload, create and manipulate images, sounds, music, animation, video, or any combination of those media (combinations may also include text and some form of interactivity).
Examples:
* [[Extension:UploadWizard|UploadWizard extension]] (running at [[commons:Special:UploadWizard]]) for simplifying media uploads
* [[Extension:SVGEdit|SVG-Edit extension]] for editing vector graphics directly in the browser
* [[Commons:Commons:Sequencer|Kaltura Sequencer]] ([[WMFBlog:2010/09/video-labs-kaltura-html5-sequencer-available-on-wikimedia-commons/|tech blog summary]]) for creating complex image/audio/video/text sequences (including templates and other wiki syntax)
||
# The upload of individual media files like images may offer opportunities for "entry-level" participation without deep engagement, while substantially enriching the content offered through Wikimedia projects.<br/>'''Strategic priority: Participation'''
# Media contribution is currently difficult even for users with mid-level experience, and improvements in this area are likely to lead to more quality content being added by existing community members.<br/>'''Strategic priority: Quality'''
# On-wiki creation or editing of media or media sequences can lead to higher quality content (and new educational approaches) being generated more quickly and, if interfaces are sufficiently intuitive, create an entry vector for contributors with rich media skillsets (videographers, illustrators, etc.), adding to community diversity.</br>'''Strategic priorities: Quality, Participation, Diversity'''
|-
| '''D.''' Editing/Contribution
||
===='''6.''' Data====
||
Features that relate to making structured and tabular data easier to enter and revise, e.g. forms, spreadsheets.
Examples:
* [[w:de:Wikipedia:Helferlein/Vorlagen-Meister|Vorlagen-Meister]] in the German Wikipedia is a gadget which makes template data editable through forms via XML descriptions.
* [http://www.wikia.com/Wikia Wikia]'s rich-text editor generates simple pop-up forms with previews to edit templates.
* [https://docs.google.com/ Google Docs Spreadsheet Component] is a sophisticated (collaborative, real-time) web-based spreadsheet editor
||
# Usability studies have shown that templates and tables are among the most complex syntax constructions in wikitext. An easier method to add and edit structured or tabular data would significantly reduce that barrier to participation. Even existing contributors are likely to be significantly more productive in an editing environment optimized for the type of content they are working on, leading to higher quality contributions. <br/>'''Strategic priority: Participation, Quality'''
|-
| '''D.''' Editing/Contribution
||
===='''7.''' Template code====
||
Features that relate to replacing or enhancing the current template programming system.
Examples:
* [[Extension:ParserFunctions|ParserFunctions]] is an example of extending wiki syntax with additional programming functions, frequently used in templates
* [http://developer.mindtouch.com/en MindTouch] is an [[w:open core|open core]] wiki engine inspired by MediaWiki that includes a Lua-like scripting language called [http://developer.mindtouch.com/DekiScript DekiScript] for dynamic content
||
# Greater programmability enhances productivity and allows the creation of richer, more dynamic content, leading to higher quality. <br/>'''Strategic priority: Quality '''
''Risks:''
* Especially to the extent that programming features mix with regular content, they can significantly increase the barriers to entry for all users and thereby reduce participation.
* There are significant performance and security challenges associated with any in-wiki programming.
|-
| '''D.''' Editing/Contribution
||
===='''8.''' Specialized content====
||
Features that relate to editing domain-specific or otherwise specialized content, e.g. music, mathematics, graphs, timelines, symbols, but also project-specific content such dictionaries (Wiktionary) or digitized text (Wikisource).
Examples:
* [[Extension:ProofreadPage|ProofreadPage]] is an extension running on Wikisource to organize collaborative proofreading and validation of digitized texts
* [http://wikisophia.org/wiki/Wikitex WikiTeX] is a general MediaWiki extension for rendering chess and go boards, chemistry, Feynman diagrams, graphs, math, music, plots, and more
||
# Richer editing tools make it possible to develop higher quality educational resources. <br/>'''Strategic priority: Quality'''
# Some specialized editing tools may go hand-in-hand with outreach to potential new editors in specific communities (e.g. better mathematics support would appeal to potential editors with mathematics expertise), some of which may add to community diversity. <br/>'''Strategic priorities: Participation, Diversity'''
|-
| '''D.''' Editing/Contribution
||
===='''9.''' Large-scale editing====
||
Features that make it possible to efficiently make additions or apply changes across a large number of pages.
Examples:
* MediaWiki's built-in [[Help:Templates|template transclusion]] system allows large-scale updates by modifying a single page (the template).
* Bots created from scratch or with frameworks like [http://pywikipediabot.sourceforge.net/ Pywikipediabot] perform millions of edits in Wikimedia projects, ranging from routine maintenance to content imports. See [[w:Wikipedia:Bots|Wikipedia:Bots]] and equivalents in other languages for background.
* [[Extension:Nuke|Nuke]] is an extension running on Wikimedia projects to mass-delete edits (used for spam prevention).
* [[Extension:Replace Text|Replace Text]] is an extension allowing search/replace operations across multiple articles.
||
# Batch-editing features reduce workload of advanced editors (allowing more time for other editing work) and enable consistent changes across large numbers of articles that would otherwise be impractical <br/>'''Strategic priority: Quality'''
|-
| '''D.''' Editing/Contribution
||
'''10.''' Maps/geodata
||
Features that relate to embedding and editing maps or geographic metadata associated with content.
Examples:
* Templates like [[w:Template:Coord]] are currently used to add geographic metadata, which is also extracted by some external applications.
* A prototype for embedding scrollable maps from OpenStreetMap is running in several production wikis, including the German Wikipedia. See [[w:de:Wikipedia:WikiProjekt Georeferenzierung/Anwendungen/OpenStreetMap/en|English language description]].
* [http://www.openstreetmap.org/ OpenStreetMap] itself is the most mature community effort to create freely licensed maps and to annotate them in various ways.
||
# Geographic information makes Wikimedia projects more useful, especially in a context of mobile uses (where a GPS or other geolocation mechanism may be used to highlight relevant information). <br/>'''Strategic priority: Quality'''
|-
| '''D.''' Editing/Contribution
||
'''11.''' Device-specific contribution
||
Features that allow the contribution of content by leveraging capabilities specific to the device that the user is using.
Examples:
* [[strategy:Proposal:Record and upload sound clips in web application]] lists some example Flash and Java audio recording tools
||
# Making it easy to contribute audio, video or images (as well as other device-specific data such as geodata) directly from a browser or app could create a very large channel of new contributions of a given type, increasing  the number of contributors and improving content quality.<br/>'''Strategic priorities: Participation, Quality'''
|-
|colspan="4" align="center" style="font-style:italic;background:#ffeaea;"|
===Collaboration: Features that support the process of working together===
|-
| '''E.''' Collaboration
||
===='''1.''' WikiProject support====
||
Features that enable more effective collaboration in (typically subject-matter oriented) groups of individuals. This is closely related to B.1. (opportunity discovery) where such features make it easier for readers/new users to join WikiProjects.
Examples:
* the [[w:User:WP 1.0 bot|WP 1.0 bot]] is used to track article assessments by more than 1,500 English Wikipedia WikiProjects
* [[w:Wikipedia:Article alerts|Article alerts]] are a bot-driven system used to track when articles within the scope of a given WikiProject enter or exit community workflows like review discussions, deletion nominations, etc.
* [http://www.quora.com/ Quora] demonstrates how productive work can be organized fluidly and effectively through social networking, e.g. by assigning topics to your friends
||
# Streamlining collaborative work with better tools is likely to increase throughput and editor retention, both of which drive quality.<br/>'''Strategic priority: Quality'''
|-
| '''E.''' Collaboration
||
===='''2.''' Process/workflow support====
||
Features which support creation of and participation in processes with a pre-determined flow (e.g. [[w:WP:FAC|Featured article candidates]], [[w:WP:FPC|Featured picture candidates]], [[w:WP:RFA|Requests for adminship]], etc.)
Examples:
* [[commons:MediaWiki:Gadget-AjaxQuickDelete.js|AjaxQuickDelete]] is a JavaScript running on Wikimedia Commons that creates a semi-automated shortcut for nominating a file for deletion
||
#  As E.1.
|-
| '''E.''' Collaboration
||
===='''3.''' Discussion and chat====
||
Features that improve people's ability to communicate in relation to their Wikimedia activity.
Examples:
* the traditional [[m:Help:Talk page|Talk page]] in its many namespace-specific incarnations and associated notification features, summary and closure templates, archival features, etc.
* the [[Extension:LiquidThreads|LiquidThreads]] extension (enabled for talk pages on this wiki) and other [[:Category:Discussion and forum extensions|discussion and forum extensions]] replace or supplement talk pages with forum features
* [[:Category:Chat extensions|chat extensions]]
||
# Usability studies have shown that users are confused and frustrated by talk pages (see talk page section of [http://bpluv.com/wikipedia/ full length videos] of the first study, for example). At the same time, interaction with advanced users is key to their effective socialization. A discussion system that is disorienting and confusing could therefore be one of the major causes of avoidable friction and frustration for new users. Fixing the discussion system is likely to improve new user socialization and thereby increase participation.</br>'''Strategic priority: Participation'''
# Even among advanced users, improved discussion systems can decrease frustration, increase productivity, and increase retention (through more reminders and notifications). Well-designed feedback loops may also be used to encourage constructive and helpful behavior. Not only could these effects on advanced users increase quality of content, they could also support the socialization of new users, by changing the behavior of advanced users towards them, and thereby increase participation.<br/>'''Strategic priorities: Quality, Participation'''
|-
| '''E.''' Collaboration
||
===='''4.''' Broadcasting tools====
||
Features that allow individual users or user groups to broadcast messages to some class of recipients.
Examples:
* [[m:Special:CentralNotice|CentralNotice]] is a sophisticated system for running various site-wide messages, targeting specific wikis, specific geographies, logged out vs. logged in users, and specific percentages of users. Messages are dismissable, translatable, and can have a start/end date. It was designed chiefly to support fundraising practices but is used for many other purposes as well (e.g. conference announcements, elections, software update notices, etc.)
* [[Extension:SiteWideMessages|SiteWideMessages]] is a simple Wikia extension that's used for broadcasting dismissable messages to talk pages. This has the advantage that longer messages are possible, and the standard talk page notification is used.
* [[Extension:MassMessage|MassMessage]] provides newsletter delivery to talk pages (see [[w:Wikipedia:Signpost/Subscribe|Wikipedia Signpost subscription service]] as an example); [[m:global message delivery|global message delivery]] is a generalized mechanism.
||
# More user-friendly and effective broadcasting to targeted classes (WikiProject members, people in a city) or subscribers  could substantially increase information flow through the Wikimedia community, thereby increasing productivity, decision-making quality and community retention. Improved regional targeting could also help with more effective face-to-face organization. These features are likely primarily going to affect users who have already joined the community, with some trickle-down participation effects. <br/>'''Strategic priority: Quality'''
|-
| '''E.''' Collaboration
||
===='''5.''' Reputation and recognition====
||
Features that support user-specific reputation and achievement metrics based on user behavior or feedback mechanisms, and which surface and apply these metrics.
Examples:
* [http://www.wikitrust.net/ WikiTrust] is an automatically computed reputation metric based on text retention.
* Wikia surfaces edit counts very visibly on user pages, and on some wikis, is using a system of leaderboards and achievements ([http://ironman.wikia.com/wiki/Special:Leaderboard example leaderboard]). Users earn achievements by completing certain actions, e.g. X number of edits, X number of images added, X number of days continually active, etc.
||
# Other than the threat of being reverted, blocked or warned, there are few mechanisms in Wikimedia that disincentivize bad user behavior. Hiding user comments, restricting access to certain tools, throttling edits and other automatic or semi-automatic responses could help mitigate bad behavior and thereby both aid attraction of new users and quality work.<br/>'''Strategic priority: Participation, Quality'''
# The flip side of the above is rewarding and recognizing good behavior in automatic or semi-automatic ways, which may have the same effect.<br/>'''Strategic priority: Participation, Quality'''
Risks:
* Automatic reputation and recognition systems may incentivize behavior that is actually undesirable (e.g. make a large number of edits regardless of quality).
* It is hard to design systems which are not somehow "gameable", leading to users spending time gaming the system for perceived rewards as opposed to engaging in the work itself, and potentially creating a social hierarchy based on accumulation of points as opposed to merit.
* Wikimedia projects are designed around collaboration, while many achievement systems are based on competitive behavior. This could cause distortions across the board, e.g. increased desire to enforce article ownership to maximize individually scored points.
|-
| '''E.''' Collaboration
||
===='''6.''' E-mail alerts====
||
Features which alert the user to important events in the Wikimedia universe by sending e-mail alerts.
* MediaWiki supports e-mail notification on changes to watchlisted articles, user talk page changes, and thread replies (with LiquidThreads).
||
# Most social media sites use e-mail aggressively to keep users engaged. More simple, lightweight, and regular notifications could help to retain contributors. <br/>'''Strategic priority: Participation'''
|-
|colspan="4" align="center" style="font-style:italic;background:#ffeaea;"|
===Quality: Features that directly support quality assurance, assessment and labeling===
|-
| '''F.''' Quality
||
===='''1.''' Ratings and Reviews====
||
Features that support attaching human quality assessments to content, and surfacing those assessments in various ways.
Examples:
* [[Extension:FlaggedRevs|Flagged Revisions]] supports multiple review levels, although it is typically only used for basic edit patrolling. On [[n:Main Page|English Wikinews]], it is used for pre-publication assessment by community-selected reviewers.
* [[Extension:ArticleFeedbackv5|Article Feedback v5]] allows reader ratings of articles according to defined categories.
* [[m:Expert review|Expert review]] describes various experiments with expert assessment of articles.
* [[Extension:Translate|Translate]] provides several [[Help:Extension:Translate/Quality assurance|quality assurance tools]].
* Rating systems can be found on countless websites, but [http://www.ted.com/ TED's rating system] is notable in allowing a reviewer to allocate a fixed number of points across certain attributes ("persuasive", "inspiring", etc.).
* co-ment-like tool for inline comments: The FSF created a very interesting software which allows to associate a comment to a single sentence or word and highlights the text accordingly.[http://gplv3.fsf.org/comments/gplv3-draft-2.html].  This could fit in other categories too, particularly Collaboration and Reader Conversion. Current implementations: [[Extension:Comments]].
||
# Reader rating and commenting systems can help surface obvious quality issues, track changes in quality over time, and open a higher throughput feedback channel to the editing community for identifying and resolving problems.<br/>'''Strategic priority: Quality'''
# Attribute-based rating systems may surface predominant characteristics of an article (show funny articles, show confusing articles) and thereby both help the editing community find obvious deficiencies, and help readers find things they are interested in.<br/>'''Strategic priorities: Quality, Reach'''
# Expert review systems may provide the most credible and thorough indicator of actual quality and change over time, informing the editing process and making the end product more useful to readers.<br/>'''Strategic priorities: Quality, Reach'''
# Both reader and expert rating systems may also serve as an entry vector for deeper engagement.<br/>'''Strategic priority: Participation'''
''Risks:''
* Too strong a focus on reviews may "cannibalize" editing, especially if there are no clear invitations to edit.
* Wikimedia is based on egalitarian principles. Expert reviews, especially if they cannot be challenged by editors, would likely cause some tension and frustration, even if they are understood to be purely advisory in nature.
|-
| '''F.''' Quality
||
===='''2.''' Vandalism response and prevention====
||
Features that reduce the mean time before destructive editing (vandalism or spam) is removed, or that prevent it in the first place.
Examples:
* the [[Extension:AbuseFilter|AbuseFilter]] is a sophisticated tool used on [[m:Abuse filter|many Wikimedia wikis]] to automatically tag edits matching user-defined filters, and to optionally show warnings, throttle future edits, or prevent the edit.
* [[w:Wikipedia:Twinkle|Twinkle]], [[w:Wikipedia:Huggle|Huggle]] and STiki are three of the most popular vandalism fighting tools, which make it easy to review edits, revert edits, report vandalism, etc. There are [[w:Wikipedia:Cleaning_up_vandalism/Tools|many others]].
* [[Extension:FlaggedRevs|Flagged Revisions]] reduces duplicate patrolling and ensures review of unreviewed ''changesets'' rather than  individual changes. (The single-revision approach can cause vandalism to be masked by a subsequent bad edit that is reverted, with the original vandalism remaining undetected.)
||
# The risk of destructive changes is inherent in an open editing environment. Preventing or at least very quickly removing destructive changes increases quality and credibility of our projects. <br/>'''Strategic priority: Quality'''
''Risks:''
* Reversion of false positives or hostile treatment of users who are making good faith mistakes or engaging in relatively innocent experimentation could turn away constructive new contributors.
|-
| '''F.''' Quality
||
===='''3.''' Page-level change tracking ====
||
Features that make it easier to analyze, understand and attribute changes within the context of a single page.
Examples:
* [http://wikipedia.ramselehof.de/wikiblame.php?lang=en&article=Main_Page WikiBlame] is a tool for searching through page histories.
* [[user:Aka|Aka]]'s [http://vs.aka-online.de/cgi-bin/wppagehiststat.pl page history statistics] and [[user:X!|X!]]'s [http://xtools.wmflabs.org/articleinfo/ articleinfo] provide lists of contributors and contribution statistics about a page.
* IBM's [http://www.research.ibm.com/visual/projects/history_flow/results.htm HistoryFlow makes it easier to understand the key contributors to a page.
* The concept of a "blamemap" is to provide a view of a page's revision that indicates text origin. [http://www.wikitrust.net/ WikiTrust] has basic blamemaps;
* [http://userscripts.org/scripts/show/1418 Wikipedia Animate] plays back changes to a page like a movie. Such features can also be found in [http://etherpad.org/ Etherpad] and [http://www.waveprotocol.org/ Google Wave]
* [http://www.w3.org/wiki/HtmlDiff Visual diff tools] show changes between two revisions as they appear to the reader (i.e. formatted), typically in a unified view (as opposed to a side-by-side view).
||
# Intuitive and quick access to the development of a page makes it more straightforward to identify and remove suspicious or false claims, and to understand the emergence of structural issues. <br/>'''Strategic priority: Quality'''
|-
| '''F.''' Quality
||
===='''4.''' Reporting tools and ticketing systems====
||
Features which make it easier for readers to report major or minor issues with a page or file.
Examples:
* Wikimedia's [[m:OTRS|OTRS]] e-mail response system is used to respond to reader reports and other issues.
* Polish and Portuguese Wikipedia, as well as several Wiktionaries, have a "Report an Error" pop-up feature that can be accessed in the sidebar ("Zgłoś błąd") and posts error reports to a [[w:pl:Wikipedia:Zgłoś błąd w artykule|dedicated wiki page]]
||
# Making it straightforward to report issues, and to track reports, could significantly increase the number of people who actively engage with Wikipedia's article content, and improve quality as a result.<br/>'''Strategic priorities: Quality, Participation'''
''Risks:''
* May cannibalize editing.
* Low signal-to-noise ratio.
|-
| '''F.''' Quality
||
===='''5.''' Page protection and edit moderation====
||
Features which restrict classes of users from making changes, or from their changes being the default-visible version.
Examples:
* [[w:Help:Protection|Page protection]] can restrict editing to some/all users
* [[Extension:FlaggedRevs|Flagged Revisions]] provides a flexible framework for forcing review of changes made by certain users, on certain or all pages, before changes become the default-visible version.
* [http://meatballwiki.org/wiki/FileReplacement FileReplacement] is a simple concept for applying changes when a timer has elapsed (revisions are integrated into a stable master copy only if a certain amount of time has passed without changes to the unstable copy)
||
# A powerful yet simple toolset for page protection and moderation will enable experienced users to ensure that any given page can be maximally open without incurring an unacceptable signal/noise ratio.<br/> '''Strategic priority: Quality'''
''Risks:''
* If the balance swings too far toward moderating or otherwise restricting changes, this could potentially severely impact new users' desire to contribute.
|-
|colspan="4" align="center" style="font-style:italic;background:#eaeaff;"|
===Languages: Features and technologies that support or enable work in and across languages===
|-
| '''G.''' Languages
||
===='''1.''' User interface localization====
||
Features which support the process of localizing MediaWiki's user interface into all supported languages, and which enable locale-specific user interface message transformations.
Examples:
* [http://translatewiki.net/ translatewiki.net] is a dedicated wiki running the [[Extension:Translate|Translate extension]] and other special software to support collaborative UI localization, and has become the primary community supporting Wikimedia localization, with new translations being fed regularly to Wikimedia projects using the [[Extension:LocalisationUpdate|LocalisationUpdate extension]].
* Beyond translation of strings, MediaWiki has many locale-specific features, from the basic (right-to-left support) to things like date formats, timezones, plural and gender transformations,  etc. See [[Localisation]] for details.
* Outside the Wikimedia universe, [https://www.transifex.net/ Transifex] has established itself as a popular and open platform for UI translation.
||
# Incomplete or broken localization will deter both readers and contributors.<br/>'''Strategic priorities: Reach, Participation, Diversity'''
|-
| '''G.''' Languages
||
===='''2.''' Text input and rendering====
||
Features which enable text input and rendering using a language's character set.
||
# Although ideally the user's operating system should take care of both typing and displaying content in the user's preferred language, in actual practice major impediments remain across operating systems and devices for many of the world's languages. Supporting input methods appropriate to the user's language, their habits and their device, and ensuring that fonts are delivered to the user if necessary, can remove critical impediments that prevent a user from contributing to or even simply using a Wikimedia project (note that input methods are also necessary for search).<br/>'''Strategic priorities: Reach, Participation, Diversity'''
|-
| '''G.''' Languages
||
===='''3.''' Collation====
||
Features that order sequences of words or phrases correctly according to a given locale.
Examples:
* The most common case where sort order matters is listing the contents of a category, or listing a set of pages. However, it is also relevant for many Wikipedia lists, and would become increasingly relevant with more automatic generation of such lists. See [[phabricator:T2164]] for a detailed discussion of this issue.
||
# For effective navigation and organization of content in a project, collation is an important factor.<br/>'''Strategic priorities: Reach, Quality'''
|-
| '''G.''' Languages
||
===='''4.''' Search indexing====
||
Features that increase the likelihood that searches return expected results in a given language, both using internal search and external search engines.
Examples:
* Search indexes need to identify word stems so that different variants of a word (actor, actress, actors, actresses) can be matched against a query. This process can vary considerably by language or script.
* [[Extension:CirrusSearch]] is used on Wikimedia projects (instead of MediaWiki's native MySQL search) and provides locale-specific features
* Character encoding can affect whether external search engines correctly index content, see [http://ultimategerardm.blogspot.com/2010/12/malayalam-enigma.html example from the Malayalam Wikipedia]
||
# If content cannot be found, it will not be read. External search issues likely have a higher priority here than internal search issues as external search tends to be the first entry-point for users discovering Wikimedia projects. <br/>'''Strategic priority: Reach'''
|-
| '''G.''' Languages
||
===='''5.''' Multilingual wikis====
||
Features that support content in multiple languages inside a single wiki.
Examples:
* [[commons:Main Page|Wikimedia Commons]] uses JavaScript and templates to a) provide user language selection, b) show templates and their contents in the user's language.
* Mindtouch Core is one of the few wiki solutions that supports [http://developer.mindtouch.com/User:dev/Specs_(Implemented)/Multiple_Languages_within_one_MindTouch_Site multiple content languages in a single wiki] using a feature called "Polyglot". See [[Multilingual MediaWiki|Multilingual MediaWiki]] for a (dated and flawed) technical and functional proposal to add similar capabilities to MediaWiki.
||
# If a websites tries to serve audiences in multiple languages, but navigation and structure of the site are not designed to support this, this can confuse both readers and contributors alike, and limit the site's overall usefulness. <br/>'''Strategic priorities: Reach, Participation, Diversity'''
|-
| '''G.''' Languages
||
===='''6.''' Multilingual discussion====
||
Features that support overcoming language barriers within the context of a single discussion.
||
# When dealing with discussion of globally shared resources, or global policies, operations and practices, the current default tends to be English (and in some cases, the shared language of the people surfacing the issue). The preference for English discriminates users by their proficiency to read and write in English. An environment that supports participation in all languages as much as possible would drive participation and diversity in multilingual communities.<br/>'''Strategic priorities: Participation, Diversity'''
|-
| '''G.''' Languages
||
===='''7.''' Translation and cross-language collaboration====
||
Features that support translating content from one wiki to another, and otherwise working together across languages on versions of a page
Examples:
* [http://translate.google.com/toolkit/ Google Translation Toolkit] is a translation user interface and workflow management tool with built-in support for Wikipedia content translation and publication.
||
# Translation can help young projects grow by translating and localizing appropriate content. It can also contribute to community diversity when perspectives are more easily shared across languages. <br/>'''Strategic priorities: Participation, Diversity'''
''Risks:''
* Translation without localization can be seen as deterring a community's organic growth and the development of content in a local language that's appropriate for the primary audience. There are also major challenges achieving high quality of translation, with or without the help of machine translation.
|-
| '''G.''' Languages
||
===='''8.''' Translation memories/glossaries====
||
Features and technologies that support re-using translations and standardizing terminologies.
Examples:
* [http://www.omegat.org/en/omegat.html OmegaT] is an open source translation memory application with MediaWiki export support.
* the [[Extension:Translate|translate extension]] supports page translation with basic translation memories
||
# As G.7. These are features that make translation work more effective and results more predictable and consistent.
|-
|colspan="4" align="center" style="font-style:italic;background:#eaeaff;"|
===Interfaces: Features and technologies that connect users and websites ===
|-
| '''H.''' Interfaces
||
===='''1.''' Authentication and authorization====
||
Features and technologies which allow a user to identify themselves (and any additional credentials and reputation), and that assign rights to a user based on their identification, either within a Wikimedia project or within an ancillary Wikimedia service.
Examples:
* [[Extension:OpenID|OpenID]] is a MediaWiki extension that allows authentication through the respective protocol (it is not currently used on Wikimedia sites)
* [{Extension:OAuth|OAuth]]
* [[w:Shibboleth (Shibboleth Consortium)|Shibboleth]] is a federated identity system especially used in the education/research sector, which could be relevant to validate expert credentials for [[m:Expert review|expert review]] systems
||
# Instant login using existing credentials could increase the number of account creations and (provided there's a good follow-up process in place) consequently increase participation. <br/> '''Strategic priority: Participation'''
# Validating credentials is a requirement for credible [[m:Expert review|expert review]].<br/>'''Strategic priority: Quality'''
# Better integration of ancillary tools and services (e.g. toolserver, OTRS) as well as external services (e.g. literature databases that provide free access to Wikimedians) is likely to encourage more innovation and tools development, as well as quicker adoption of new tools and services.<br/>'''Strategic priorities: All/Innovation'''
|-
| '''H.''' Interfaces
||
===='''2.''' Share/invite activity via social media====
||
Features and technologies which enable users to share identified activities such as article creation, file uploads, etc. on social media feeds.
Examples:
* Many sites like Flickr ([http://www.flickr.com/help/sharing/#953361 relevant FAQ entry]) make it easy to share all or some uploads to Twitter or Facebook. The simplest implementation is the "Share this" menu common on many websites (including [[n:Template:Social bookmarks|Wikinews]]), while more advanced implementations semi-automatically or automatically post updates as a normal part of the user's interaction with the site.
||
# Social gaming like [[w:FarmVille|FarmVille]] has demonstrated how sharing your activity can draw other people in successfully (and alienate all your friends). Especially when posting to social media feeds (automatically or semi-automatically) also includes explicit invitations to participate, it may be one of the most scalable ways to draw in new contributors, which may also reflect a more diverse background than would self-select to join the community.<br/>'''Strategic priorities: Participation, Diversity'''
''Risks:''
* If updates to social media are perceived as too frequent or as irrelevant, they may create a negative perception associated with Wikimedia activities, much like a negative perception is often attached to social gaming. Making updates interesting, and only sharing significant events, could be of key importance to prevent this.
* Not every user is suitable to be sucked into every type of activity. Undiscriminated broadcasting of invitations to join may lead to negative experiences both for potential new contributors and for experienced Wikimedians. Targeted social media invitations (especially in communities that are structured by domain expertise, like [http://www.quora.com/ Quora]) may be more effective.
|-
| '''H.''' Interfaces
||
===='''3.''' Find friends from social media====
||
Features and technologies which make it possible to transport your social graph to Wikimedia wikis. This assumes the existence of a local social graph, although it could be a rudimentary one.
Examples:
* The mainstream social media sites try to make it as easy as possible to find friends by importing information from other sites (cf. Facebook's Friend Finder). They also evaluate local social graphs to suggest new friends (X people you know are friends with Y, maybe you should be friends with Y, too).
* [http://www.plaxo.com/ Plaxo] is just one of many Web 2.0 applications that allows import of identity and address books from a large number of email and social networking services.
||
# Being able to quickly find people you know on Wikimedia would make it easier for new community members to get started and make Wikimedia a more natural part of their social experience, aiding continued participation. <br/>'''Strategic priority: Participation'''
''Risks:''
* The Wikimedia community is relatively small, with no project/language community having more than tens of thousands of active members at a given time. It's not clear what the typical success rate would be in finding people in your network who have been recently active.
* Maintaining a local social graph may bring with it considerable unwanted baggage, such as the privacy requirements that come with it. To the extent that such features open the door to general development of an explicit social network, there are risks of distorting community activities and priorities.
|-
| '''H.''' Interfaces
||
===='''4.''' Discover/review/import free content====
||
Features that leverage the APIs and feeds of other websites for the purpose of updating or importing content.
Examples:
* [[strategy:Proposal:Media review]] is a more general high-level proposal for media review tools.
* [[w:Wikipedia:WikiProject Citizendium Porting|WikiProject Citizendium Porting]] is one of many very manual review processes currently employed by the community to import relevant free content.
||
# Flickr alone contains tens of millions of photographs under Creative Commons licenses acceptable to the Wikimedia community. Obviously not all those photos are relevant, but it is likely that the number of useful pictures outnumbers the number of currently used pictures from Flickr at least by an order of magnitude. Effective review and import tools could therefore add a lot of useful content to our projects with relatively little effort. <br/>'''Strategic priority: Quality'''
# The review part of the pipeline is especially significant to efforts in the multimedia space which are likely to introduce a large number of uploads with low signal/noise ratio, e.g. uploads from smartphones. Here, having a standard mechanism to review content can help to ensure that uploaders aren't turned away by deletions, and that community members are not overwhelmed by the inflow.<br/>'''Strategic priorities: Quality, Participation'''
|-
| '''H.''' Interfaces
||
===='''5.''' Cross-wiki integration====
||
Features that create a more consistent and persistent experience across Wikimedia projects.
Examples:
* [[:w:User:DannyS712/Global watchlist|Global watchlist]] and [https://tools.wmflabs.org/guc Global Contributions] are examples of projects which bridge gaps created by separate project instantiations of these features.
* [[m:CommonsTicker|CommonsTicker]] was a complex notification system used between 2006-2008 to notify Wikimedia projects of relevant events such as image deletions, so that they could make necessary modifications or engage in discussions on Commons.
* [[Extension:GlobalUsage|GlobalUsage]] is one of relatively few production use features that share information across Wikimedia projects, in this case, usage information of media files on Wikimedia Commons.
||
# Due to the fragmentation of tools like recent changes lists, watchlists, user profiles and individual contributions, there's no consistent experience across Wikimedia projects. The more projects one is active in, the larger the impact on one's workflows and effectiveness. Since participation in multiple projects is almost required to become a productive Wikimedian (e.g. Commons, Meta), this is more significant as a deterrent than may be intuitively obvious. Minimizing the gap between projects could ensure a more steady flow from mid-level engagement on a single project to high-level engagement across the Wikimedia universe.<br/>'''Strategic priorities: Participation, Quality'''
# Beginning with tighter integration of the Wikimedia experience would likely help lay the foundations of how the Wikimedia experience could be integrated with collaboration in other wikis. (An example where this has happened is [[InstantCommons|InstantCommons]], giving remote wikis essentially the same toolset that Wikimedia wikis enjoy.) Ultimately, this could be transformative in developing more of a knowledge ecosystem that recognizes the value of specialized communities, and makes it easy for contributors to cross virtual boundaries.<br/>'''Strategic priorities: Participation'''
|-
| '''H.''' Interfaces
||
===='''6.''' APIs====
||
Features that expose Wikimedia functionality through machine-accessible interfaces.
Examples:
* MediaWiki ships with a reasonably powerful, self-documenting API ([http://en.wikipedia.org/w/api.php English Wikipedia API help page])
||
# Exposing currently missing functionality through the API enables application developers (Wikimedians and others) to build tools leveraging it, leading to more innovation and decentralized product development.<br/>'''Strategic priorities: All/Innovation'''
|-
|colspan="4" align="center" style="font-style:italic;background:#eaeaff;"|
===Platform: Technologies that support or enable feature development===
|-
| '''I.''' Platform
||
===='''1.''' Performance====
||
Changes to technology which are solely focused on reducing the perceived and actual time a transaction takes to complete.
Examples:
* Many of MediaWiki's native features are designed to support concurrent usage by vast numbers of users. This includes Squid caching of text, memory caching of user interface texts, database replication, and more. See [[Manual:Performance tuning|Manual:Performance tuning]] for some examples.
* [[ResourceLoader|ResourceLoader]] is a technology specifically developed to speed up performance of JavaScript/CSS delivery, affecting front-end performance.
* Aside from specific code optimizations, source code transformers like [https://github.com/facebook/hiphop-php/wiki/ HipHop], alternative caching implementations like [http://www.varnish-cache.org/ Varnish], alternative protocols like [https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper SPDY] and various technologies collectively known as [[w:NoSQL|NoSQL]] are examples of tools and technologies that represent future frontiers for Wikimedia performance optimization.
||
# Countless studies have shown that site performance has a major impact on user behavior and abandonment. If new features are implemented without regard for site performance impact, any positive benefit could be canceled out by worsening of performance. Even without any other new features, improved site performance can increase users' likelihood to visit and to contribute.<br/>'''Strategic priorities: Reach, Participation'''
|-
| '''I.''' Platform
||
===='''2.''' Wikitext====
||
Changes to the markup representation of Wikimedia content, and to how it is interpreted.
Examples:
* Wikimedia Foundation sites use a number of extensions that add specific features that can be invoked through wiki markup. [[Extension:ParserFunctions|ParserFunctions]] represents one of the deeper changes that adds programming features especially used in templates, while most other extensions (e.g. citations, mathematics, templates) are used to enrich the content more directly.
* [http://semantic-mediawiki.org/ Semantic MediaWiki] (see below) adds some wiki markup features for its functionality.
* There are a number of [[Alternative parsers|alternative parser implementations]]. Attempts to define standardized wiki markup used across different implementations, such as [http://www.wikicreole.org/ WikiCreole], have largely failed to gain traction.
||
# Making wiki-markup predictably parseable in both directions (from markup to HTML and back again, perhaps using an intermediate representation) may be a necessary precondition for the development of a stable rich-text editor that allows markup-based editing to coexist with rich-text editing, as well as other future editing surface implementations that we may want to develop.<br/>'''Strategic priority: Participation'''
# Virtually every third party use of Wikimedia content tends to sooner or later run into challenges that require parsing the markup, as opposed to just dealing with static HTML. A stable, flexible, performant and complete parser implementation supports these third party uses, which primarily relate to getting Wikimedia content into more applications and to more people.<br/>'''Strategic priority: Reach'''
# A more flexible parser can generate multiple output formats, e.g. PDF and EPUB, which is useful for offline projects.<br/>'''Strategic priority: Reach'''
# Improving interchangeability of content, with all semantics intact, across collaborative systems  supports the development of a richer knowledge ecosystem.<br/> '''Strategic priorities: Participation, Quality'''
|-
| '''I.''' Platform
||
===='''3.''' File type support====
||
Features and technologies which enable certain files to be securely uploaded and viewed.
Examples:
* Although Wikimedia is understandably conservative with regard to security issues raised by supporting new file types, dedicated support exists in production for Ogg Theora (video), Ogg Vorbis (audio), TIFF, DjVu and SVG (images), and PDF.
* Frequently requested file formats include the the [http://www.blender.org/ Blender] 3D file format and the [[w:COLLADA|COLLADA]] 3D exchange format, [[w:OpenDocument|OpenDocument]] formats, and [[w:Scribus|Scribus]] DTP files
* [https://developer.mozilla.org/en/Configuring_servers_for_Ogg_media Certain server-side configuration changes] are recommend to provide a seamless experience when serving video.
* For dramatically broadening the number of filetypes that can uploaded at least by some users, some mechanisms for restricted uploads may be desirable -- see [[commons:Commons:Restricted uploads|related proposal]].
||
# Support for uploading the source(s) underlying a particular media file (for example the 3D model used to generate a 2D image) is essential for modifiability and re-usability, which in turn is a precondition for content localization, collaboration and continuing iterative improvement even after an uploader has lost interest. <br/>'''Strategic priority: Quality'''
# Improving support for video playback and upload can enable new contributors, help us reach new audiences, and open up new opportunities to improve content.<br/>'''Strategic priorities: Reach, Participation, Quality'''
|-
| '''I.''' Platform
||
===='''4.''' Access controls====
||
Features and technologies which allow selective restrictions of read or write permissions for a given resource.
Examples:
* The combination of [[Help:Protected pages|page protections]], [[Help:Blocking users|user blocks]] and [[Help:Sysops and permissions|administrators]] are three pillars of the access controls employed in Wikimedia's projects, moderating open editability with page-specific restrictions and selective restrictions placed on users who violate community norms.
* [[:Category:Page specific user rights extensions|Page-specific user rights extensions]] provides an overview of various MediaWiki extensions providing additional access control features, with appropriates caveats.
||
# Such features are primarily of interest in a corporate context, where privileged information (e.g. a hire announcement) is often worked on by a small number of people prior to being shared in a larger group context (which could be a wiki where the content is then further edited). In these contexts, wiki access controls may therefore reduce the need to employ multiple tools. The primary stakeholders benefiting from this in the context of the Wikimedia movement are the various organizational entities (WMF and chapters), with only indirect impact on their strategic priorities. This also includes open-read/restricted-write collaboration spaces like the [[wmf:Home|Wikimedia Foundation website]], which could be merged into a public space like [[m:|Meta]] if better access controls existed.<br/>'''Strategic priority: No direct strategic impact'''
# An additional and related impact hypothesis is that a MediaWiki ecosystem that supports functionality needed by corporate users well is going to lead to more decentralized innovations by these users, which would ultimately impact Wikimedia priorities as well. <br/>'''Strategic priority: Innovation'''
''Risks:''
* Scope creep is the flip-side of more decentralized innovation. A greater need to support a multiplication of use cases could lead to the "drupalification" of MediaWiki into a general purpose platform with limited focus on the specific needs of Wikimedia projects.
|-
| '''I.''' Platform
||
===='''5.''' Accessibility====
||
Features and assistive technologies which help groups of people with disabilities or special needs to use Wikimedia projects.
Examples:
* Accessibility tends to be a function of lots of small changes designed to support users well in a variety of contexts (see [https://phabricator.wikimedia.org/maniphest/?project=PHID-PROJ-ixlw2snbnwrgasygw4ko&statuses=open()&group=none&order=newest#R list of open bugs with the accessibility tag]). There are some proposals for major features (cf. [[strategy:Proposal:text-to-speech]] and [[Extension:SignWriting MediaWiki Plugin|SignWriting extension]]).
* W3C's [http://www.w3.org/WAI/intro/aria.php WAI-ARIA] is a planned standard to make rich internet applications more accessible, and is especially relevant to applications like MediaWiki which increasingly rely on JavaScript for key user features.
||
# When users encounter major accessibility issues, they may not be able to consume content, and they may not be able to contribute (effectively or at all). Overcoming accessibility issues may also help us to gain contributors whose perspectives and voices we would otherwise miss.<br/>'''Strategic priorities: Participation, Diversity'''
|-
| '''I.''' Platform
||
===='''6.''' Hardware support====
||
Platform technologies for accessing device-specific capabilities.
Examples:
* The official [http://itunes.apple.com/app/wikipedia-mobile/id324715238?mt=8 Wikipedia iPhone app] uses device capabilities to provide geo-location information.
* [http://dev.w3.org/2009/dap/camera/ HTML media capture] defines standards used to accept device input in web applications. More specific access to hardware capabilities is typically granted through APIs which can be accessed through natively implemented applications.
||
# Making MediaWiki (both core and mobile codebase) flexible in terms of device access will enable richer participation and a greater reader experience than is currently possible.<br/>'''Strategic priorities: Reach, Participation'''
|-
| '''I.''' Platform
||
===='''7.''' Structured data====
||
Features and technologies which relate to expressing, storing, searching and retrieving structured data within and about Wikimedia content.
Examples:
* [http://dbpedia.org/ DBPedia] is the largest community effort to extract structured data from Wikipedia.
* [http://semantic-mediawiki.org/ Semantic MediaWiki] is a powerful ecosystem of MediaWiki extensions making it possible to edit, store and query data inside a MediaWiki instance.
* [http://shortipedia.org/index.php/Main_Page Shortipedia] is a lightweight implementation of a central data repository using Semantic MediaWiki as its backend.
* [http://omegawiki.org/ OmegaWiki] is a project to "create a dictionary of all words of all languages, including lexical, terminological and ontological information", originally inspired by the perceived weaknesses of the current Wiktionary approach.
* [[w:WikiProject Microformats|WikiProject Mircoformats]] on English Wikipedia is a community effort to add relevant microformats to Wikimedia content.
* [[:de:Hilfe:Personendaten|Biographical data]] is systematically added to articles in the German Wikipedia, including cross-references to library records. A toolserver database exists to provide biographical summary information and look up records in other databases ([http://toolserver.org/~apper/pd/person/Wilhelm_Schmidt_(Ethnologe) example page]).
||
# Eliminating redundancies of structured data in Wikimedia projects will dramatically increase productivity and consistency of information across Wikimedia language editions.<br/>'''Strategic priority: Quality'''
# Replacing manually maintained lists with automatic queries will allow us to provide more useful, more up-to-date and more flexible lists and reports to our readers.<br/>'''Strategic priority: Quality'''
# Better semantics for data will allow us to create data-aware editing interfaces, which will create new opportunities for participation and make existing data-related editing work more productive.<br/>'''Strategic priorities: Quality, Participation'''
# Many of Wikimedia's current projects are highly data-driven, and the user experience in these projects is consequently poor, which affects both end users and participants. The two projects most affected by this are Wikimedia Commons (file metadata is maintained in templates) and Wiktionary (pages are essentially a mix of templates). For these projects, designing the application to better support the data contained therein could dramatically boost participation and reach, resulting in further innovations down the line.<br/>'''Strategic priorities: Reach, Participation, Innovation'''
# Wikipedia is emerging as a canonical description of reality used in countless web products (Facebook, LinkedIn, Bing, etc.). All of these products have had to do their own processing of Wikimedia content or rely on DBPedia because we do not provide data contained in Wikimedia projects in a useful form. This creates a high barrier to entry for new innovative initiatives and inconsistent quality experiences. A platform that's built to support data-driven applications will lead to more innovation, especially impacting reach of our content.<br/>'''Strategic priorities: Reach, Innovation'''
|-
| '''I.''' Platform
||
===='''8.''' Social graph====
||
Technologies that relate to tracking connections between users and evaluating them meaningfully.
Example:
* Every social network, by definition, maintains a social graph (Facebook, LinkedIn, etc.). Within wikis, [[Extension:SocialProfile|SocialProfile]] is an example of a simple friend (and foe) system without some of the more complex features present in social media.
||
# A social graph is preconditional for many wiki-internal social features, enabling the associated benefits. <br/>'''Strategic priorities: Participation, Quality, Diversity'''
''Risks:''
* If social features are not carefully designed around a wiki's primary purpose, they may distract from that purpose and lead to the development of subcultures whose objectives aren't aligned and may be actively harmful. They could also lead to reinforcement of factions and associated accusations/suspicions.
* Maintaining a database of social connections raises a host or privacy issues that we are currently not dealing with, e.g., if these connections are visible, anyone could evaluate them in order to determine a user's identity, location, etc.
|-
| '''I.''' Platform
||
===='''9.''' Labs and research infrastructure====
||
Technologies which relate to testing and experimental development of functionality.
Examples:
* [https://tools.wmflabs.org/admin// Toolforge] is an environment where volunteers, researchers and staffers can build, test and run experimental software consistent with Wikimedia's mission. The environment provides not only computing resources and a web server, but also access to a full read-only replica of Wikimedia's databases, making it possible to run arbitrary queries in real-time. This has led to lots of bottom-up innovation directly responsive to community needs.
* the [[Extension:OpenStackManager|OpenStackManager]] is an extension that will potentially make it possible to flexibly manage access to virtualized servers running in WMF's cluster.
||
# An environment which makes it easy to a) get access to computing resources, b) get access to live databases, c) get access to public datasets, d) commit and branch code, e) instantiate this code either in the form of simple scripts or full MediaWiki instances (the latter resembling production configurations if desired), f) get access to user data needed for an application through mechanisms like OAuth, g) test code on a number of virtualized platforms and operating systems, could become a major platform for innovation and bleeding edge development, as well as  supporting general MediaWiki development on a continual basis by making it trivial to stage and test code.<br/>'''Strategic priority: Innovation'''
|-
|}
<div style="font-size:1.5em;text-align:center;font-weight:bold;">Want to make a quick suggestion? [[/Parking lot|Add it to the parking lot!]]</div>
[[Category:MediaWiki development]]

2020年10月30日 (五) 07:53的版本

数据库

What are the differences between MediaWiki, Wikimedia, Wikipedia and wiki?

This is a common question; please see for a detailed answer.

取自“https://clwfcc.com/wiki/index.php?title=FAQ&oldid=572”