| Product area |
Subcategory |
Brief description |
Strategic impact hypothesis
|
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:
|
- 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.
Strategic priority: Reach
- Our potential for converting readers to active participants increases by engaging new readers, or by deepening engagement with existing readers.
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:
|
- 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.
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:
- Wiki-Surf adds a "related articles" panel to Wikipedia searches.
- Wikipedia Diver graphs articles you've visited in a Firefox session (defunct?).
- The 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.
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:
|
- 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.
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.
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 CategoryTree extension in use on Wikimedia projects eases traversing categories
- In the 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:
|
- 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.
Strategic priorities: Reach
|
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:
|
- 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%)" [1]. 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.
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:
- In the context of the article feedback feature (which allows simple star-rating of articles), we are experimenting with calls to action after a user has submitted a rating.
- Image uploads from smartphones, in combination with a feature-set like media review, may provide a simple feel-good way to help Wikimedia projects, which could be leveraged for further engagement.
- HotCat and 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.
Strategic priority: Participation
|
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:
|
- 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.
Strategic priority: Participation
|
| C. New Editor Support
|
|
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 mentoring program in the German Wikipedia is one of the largest scale community efforts to help new users. It is supported by a toolserver-powered mentor/mentee tracker and an IRC chat room.
- There are similar programs in other languages (e.g. Adopt-a-user in the English Wikipedia), and more targeted programs like the ambassadors supporting university course assignments. The ambassadors also use IRC chat (with a webchat interface) for help and support.
- A more comprehensive LiveHelp concept can be found on the OutreachWiki.
|
- 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.
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.
Strategic priority: Diversity
|
| C. New Editor Support
|
3. Interaction with advanced users
|
Features that systematically ease friction between new and experienced users.
Examples:
- The 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 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.
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 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 page creation and 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.
Strategic priority: Participation
|
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:
|
- 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.
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.
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:
|
- 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.
Strategic priority: Participation
- Better tools for quick changes are likely to significantly increase the productivity of experienced editors.
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:
- wikEd, "a full-featured Wikipedia-integrated advanced text editor for regular to advanced wiki users", which supports reference and template folding.
- Improvements by the usability initiative, including some which aren't staged, such as template folding, navigation inside the editor, and improved preview/save workflow.
- The Ace editor (demo) is an HTML5-based code editor "that matches and extends the features, usability and performance of existing native editors such as TextMate, Vim or Eclipse".
|
- 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).
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.
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:
|
- Enabling synchronous editing could increase productivity by essentially eliminating 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.
Strategic priorities: Participation, Quality
|
| D. Editing/Contribution
|
|
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:
|
- 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.
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.
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.
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:
- Vorlagen-Meister in the German Wikipedia is a gadget which makes template data editable through forms via XML descriptions.
- Wikia's rich-text editor generates simple pop-up forms with previews to edit templates.
- 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.
Strategic priority: Participation, Quality
|
| D. Editing/Contribution
|
7. Template code
|
Features that relate to replacing or enhancing the current template programming system.
Examples:
- ParserFunctions is an example of extending wiki syntax with additional programming functions, frequently used in templates
- MindTouch is an open core wiki engine inspired by MediaWiki that includes a Lua-like scripting language called DekiScript for dynamic content
|
- Greater programmability enhances productivity and allows the creation of richer, more dynamic content, leading to higher quality.
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:
- ProofreadPage is an extension running on Wikisource to organize collaborative proofreading and validation of digitized texts
- 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.
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.
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 template transclusion system allows large-scale updates by modifying a single page (the template).
- Bots created from scratch or with frameworks like Pywikipediabot perform millions of edits in Wikimedia projects, ranging from routine maintenance to content imports. See Wikipedia:Bots and equivalents in other languages for background.
- Nuke is an extension running on Wikimedia projects to mass-delete edits (used for spam prevention).
- 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
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 English language description.
- 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).
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:
|
- 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.
Strategic priorities: Participation, Quality
|
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:
- Igor is a stand-alone multi-functional WikiProject management tool written in Java (early development, now defunct)
- the WP 1.0 bot is used to track article assessments by more than 1,500 English Wikipedia WikiProjects
- 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.
- 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.
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. Featured article candidates, Featured picture candidates, Requests for adminship, etc.)
Examples:
- AjaxQuickDelete is a JavaScript running on Wikimedia Commons that creates a semi-automated shortcut for nominating a file for deletion
- DeleteQueue is an abandoned MediaWiki extension for deletion workflows
- Workflow is an extension that allows users to cycle through defined state changes using an AJAX UI (example, requires user account)
- Tasks, Tasks Extension and Todo Tasks are tools for managing page-dependent task lists and related workflows
|
- 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 Talk page in its many namespace-specific incarnations and associated notification features, summary and closure templates, archival features, etc.
- the LiquidThreads extension (enabled for talk pages on this wiki) and other discussion and forum extensions replace or supplement talk pages with forum features
- Chat extension which adds webchat channels to each page (demo) and other chat extensions
- Reflect extension which allows simple inline summarization at the comment level. Intended to a) make it easier for people to get the 'gist' of long talk page discussions, b) pull out/highlight the most important bits from a conversation, and c) encourage active listening and restatement of what others say (hopefully helping to increase common ground, diffuse flamewars). Reflect is currently integrated with Extension:LiquidThreads.
|
- Usability studies have shown that users are confused and frustrated by talk pages (see talk page section of 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.
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.
Strategic priorities: Quality, Participation
|
| E. Collaboration
|
|
Features that allow individual users or user groups to broadcast messages to some class of recipients.
Examples:
- 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.)
- 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.
- User:SoxBot is one of many bots used for newsletter delivery to talk pages (see Wikipedia Signpost subscription service as an example); 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.
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:
- 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 (example leaderboard). Users earn archievements by completing certain actions, e.g. X number of edits, X number of images added, X number of days continually active, etc.
- The Wikimedia Foundation's Public Policy Initiative maintains a leaderboard of students ranked by the amount of text contributed.
|
- 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.
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.
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.
Strategic priority: Participation
|
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:
- Flagged Revisions supports multiple review levels, although it is typically only used for basic edit patrolling. On English Wikinews, it is used for pre-publication assessment by community-selected reviewers.
- Article Feedback allows reader ratings of articles according to defined categories.
- Wikinews runs a modified version of the old ReaderFeedback extension (the predecessor to ArticleFeedback) with built-in commenting via LiquidThreads. It's used for reader ratings of articles (example; see footer)
- Expert review describes various experiments with expert assessment of articles.
- CommunityVoice enables in-line ratings anywhere in a page.
- Translate provides several quality assurance tools.
- Rating systems can be found on countless websites, but 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.[2]. This could fit in other categories too, particularly Collaboration and Reader Conversion. Current implementations: Extension:Comments, Extension:Annotator.
|
- 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.
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.
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.
Strategic priorities: Quality, Reach
- Both reader and expert rating systems may also serve as an entry vector for deeper engagement.
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 AbuseFilter is a sophisticated tool used on many Wikimedia wikis to automatically tag edits matching user-defined filters, and to optionally show warnings, throttle future edits, or prevent the edit.
- WPCVN is an (alpha-code) collaborative web-based vandalism prevention tool which uses trust metrics to highlight suspicious edits (now defunct).
- Twinkle, 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 many others.
- 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.
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:
|
- 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.
Strategic priority: Quality
|
| F. Quality
|
|
Features which make it easier for readers to report major or minor issues with a page or file.
Examples:
- Wikimedia's 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 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.
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:
- Page protection can restrict editing to some/all users
- 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.
- 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.
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.
|
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:
- translatewiki.net is a dedicated wiki running the 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 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, Transifex has established itself as a popular and open platform for UI translation.
|
- Incomplete or broken localization will deter both readers and contributors.
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.
Examples:
|
- 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).
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 bugzilla:164 for a detailed discussion of this issue.
|
- For effective navigation and organization of content in a project, collation is an important factor.
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.
- Lucene-search and MWSearch are used on Wikimedia projects (instead of MediaWiki's native MySQL search) and provide locale-specific features
- Character encoding can affect whether external search engines correctly index content, see 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.
Strategic priority: Reach
|
| G. Languages
|
5. Multilingual wikis
|
Features that support content in multiple languages inside a single wiki.
Examples:
- 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 multiple content languages in a single wiki using a feature called "Polyglot". See 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.
Strategic priorities: Reach, Participation, Diversity
|
| G. Languages
|
6. Multilingual discussion
|
Features that support overcoming language barriers within the context of a single discussion.
Examples:
- Multilingual LiquidThreads is a research project to add the functionality needed for having a discussion in multiple languages (machine translation, human translation, dictionaries) to LiquidThreads
|
- 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.
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:
- Google Translation Toolkit is a translation user interface and workflow management tool with built-in support for Wikipedia content translation and publication.
- WikiBhasha is a cross-language collaboration and content creation tool that makes it easy to pull and translate content from other languages where relevant. The front-end is open source, and it functions as an overlay to the normal editing experience.
|
- 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.
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:
- OmegaT is an open source translation memory application with MediaWiki export support.
- the 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.
|
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:
- OpenID and Facebook are MediaWiki extensions that allow authentication through the respective protocols (neither is currently used on Wikimedia sites)
- Shibboleth is a federated identity system especially used in the education/research sector, which could be relevant to validate expert credentials for expert review systems
- Toolserver User Screening Control is an authentication hack to validate Wikimedia identities for the purpose of toolserver projects (it does so by requiring the user to place a unique hash on their talk page!). This kind of hack would be unnecessary if proven technologies like OAuth were adopted.
|
- 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.
Strategic priority: Participation
- Validating credentials is a requirement for credible expert review.
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.
Strategic priorities: All/Innovation
|
| H. Interfaces
|
|
Features and technologies which enable users to share identified activities such as article creation, file uploads, etc. on social media feeds.
Examples:
- Nihiltres maintains a list of "wiki-article tweeters", bots or accounts that are constantly posting content updates or random articles from specific Wikimedia projects on Twitter. Examples include @en_wikinews (news stories), @Artikelgeburt (new German Wikipedia articles), and @wikibooksbot (random English Wikibooks pages).
- Many sites like Flickr (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 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 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.
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 Quora) may be more effective.
|
| H. Interfaces
|
|
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).
- 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.
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:
- FlickrLickr is a bot with a backend that uses the Flickr API to make it possible to review and import freely licensed Flickr images. It provides a dedicated front-end for reviewing slices of 1,000 pictures (50 pictures per page), which includes selection of relevant images and any necessary metadata changes.
- strategy:Proposal:Media review is a more general high-level proposal for media review tools.
- 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.
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.
Strategic priorities: Quality, Participation
|
| H. Interfaces
|
5. Cross-wiki integration
|
Features that create a more consistent and persistent experience across Wikimedia projects.
Examples:
- Global Watchlist and Global Contributions are examples of toolserver tools which bridge gaps created by separate project instantiations of these features.
- 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.
- 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.
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, 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.
Strategic priorities: Participation
|
| H. Interfaces
|
6. APIs
|
Features that expose Wikimedia functionality through machine-accessible interfaces.
Examples:
|
- 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.
Strategic priorities: All/Innovation
|
|
|
| I. Platform
|
|
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 for some examples.
- 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 HipHop, alternative caching implementations like Varnish, alternative protocols like SPDY and various technologies collectively known as 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 (example). 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.
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. 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.
- Semantic MediaWiki (see below) adds some wiki markup features for its functionality.
- There are a number of alternative parser implementations, with mwlib being one of the most mature ones used in Wikimedia production. Attempts to define standardized wiki markup used across different implementations, such as 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.
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.
Strategic priority: Reach
- A more flexible parser can generate multiple output formats, e.g. PDF and EPUB, which is useful for offline projects.
Strategic priority: Reach
- Improving interchangeability of content, with all semantics intact, across collaborative systems supports the development of a richer knowledge ecosystem.
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 Blender 3D file format and the COLLADA 3D exchange format, OpenDocument formats, and Scribus DTP files
- 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 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.
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.
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 page protections, user blocks and 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.
- 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 Wikimedia Foundation website, which could be merged into a public space like Meta if better access controls existed.
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.
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:
|
- 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.
Strategic priorities: Participation, Diversity
|
| I. Platform
|
6. Hardware support
|
Platform technologies for accessing device-specific capabilities.
Examples:
- The official Wikipedia iPhone app uses device capabilities to provide geo-location information.
- 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.
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:
- DBPedia is the largest community effort to extract structured data from Wikipedia.
- Semantic MediaWiki is a powerful ecosystem of MediaWiki extensions making it possible to edit, store and query data inside a MediaWiki instance.
- Shortipedia is a lightweight implementation of a central data repository using Semantic MediaWiki as its backend.
- 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.
- WikiProject Mircoformats on English Wikipedia is a community effort to add relevant microformats to Wikimedia content.
- 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 (example page).
|
- Eliminating redundancies of structured data in Wikimedia projects will dramatically increase productivity and consistency of information across Wikimedia language editions.
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.
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.
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.
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.
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, 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.
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:
- The toolserver 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 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.
Strategic priority: Innovation
|
