Outreach programs/Possible projects

We are using this list of projects as a master branch for Mentorship programs such as Google Summer of Code and Outreach Program for Women. The projects listed are good for students and first time contributors but they require a good amount of work. They might also be good candidates for Individual Engagement Grants.


 * Featured project ideas usually have mentors ready for you to jump in.
 * Ongoing tasks are neverending (but fun) activities with mentors available, although they might not be suitable for e.g. GSOC.
 * Raw projects are interesting ideas that have been proposed but might lack definition, consensus or mentors, and therefore we can't feature them.

If you are looking for smaller tasks check the Annoying little bugs. For a more generic introduction check How to contribute.



Be part of something big
We believe that knowledge should be free for every human being. We prioritize efforts that empower disadvantaged and underrepresented communities, and that help overcome barriers to participation. We believe in mass collaboration, diversity and consensus building to achieve our goals.

Wikipedia has become the fifth most-visited site in the world, used by more than 400 million people every month in more than 270 languages. We have other content projects including Wikimedia Commons, Wikidata and the most recent one, Wikivoyage. We also maintain the MediaWiki engine and a wide collection of open source software projects around it.

But there is much more we can do: stabilize infrastructure, increase participation, improve quality, increase reach, encourage innovation.

You can help to these goals in many ways. Below you have some selected ideas.

Where to start
Maybe at this point your proposal is just a vague idea and you want to get some feedback before investing much more time planning it? We know this feeling very well! Just send an email to wikitech-l (or qgil@undefinedwikimedia.org if you prefer) sharing what you have in mind. One short paragraph can be enough to get back to you and help you working in the right direction.

Any potential contributor new to our community is encouraged to follow the Landing instructions. Use your user page to introduce yourself and draft your project (use the template). The GSOC student guide is a good resource for anybody willing to write a good project proposal. And then there is a list of DOs and DON'Ts full of practical wisdom.

To set up your MediaWiki developer environment, we recommend you start installing a local instance using mediawiki-vagrant. You can also have a fresh MediaWiki to test on a remote server. Just get developer access and request your own instance at Wikitech.

If you have general questions you can start asking at the |Discussion page. IRC channel is also a good place to find people and answers. We do our best connecting project proposals with Bugzilla reports and/or wiki pages. Other contributors may watch/subscribe to those pages and contribute ideas to them. If you can't find answers to your questions, ask first in those pages. If this doesn't work then go ahead and post your question to the wikitech-l mailing list.

Featured project ideas
Below you can find a list of ideas that already have gone through a reality check and have mentors confirmed. You can find more suggestions in our list of Raw projects.

But before, let us talk about...

Your project
That's right! If you have a project in mind we want to hear about it. We can help you assessing its feasibility and we will do our best finding a mentor for it.

Here you have some guidelines for project ideas:


 * Opportunity: YES to projects responding to generic or specific needs. YES to provocative ideas. NO to trivial variations of existing features.
 * Community: YES to projects encouraging community involvement and maintenance. NO to projects done in a closet that won't survive without you.
 * Deployment: YES to projects that you can deploy. YES to projects where you are in sync with the maintainers. NO to projects depending on unconvinced maintainers.
 * MediaWiki != Wikipedia: YES to generic MediaWiki projects. YES to projects already backed by a Wikimedia community. NO to projects requiring Wikipedia to be convinced.
 * Free content: YES to use, remix and contribute Wikimedia content. Yes to any content with free license. NO to proprietary content.
 * Free API: YES to the MediaWiki API. Yes to any APIs powered with free software. NO to proprietary APIs.



Reuse / Remix / Contribute to Wikimedia content
The Wikimedia community maintains millions of articles, media files and data that anybody (including your software) can download, share, modify, remix. We offer a MediaWiki API to interact with this content in the Wikimedia servers. An API that is also available in most MediaWiki based sites.

We welcome projects aiming to get this content to the people that need it most. Projects converting regular users in contributors to the Wikimedia pool of free knowlege. Projects categorizing, connecting or remixing this content and obtaining better or simply unexpected results. Surprise us!

We also welcome improvements to the API, enabling the enablers. Localized errors and warnings, RESTful style Content API, API versioning and Wikidata API are some of the features waiting for a developer in our API roadmap.

Skills: depends on your project, but understanding PHP will be good in any case.

Mentors: Yurik Astrakhan as default. Others might be available depending on your project.

VisualEditor plugins
VisualEditor is a rich visual editor for all users of MediaWiki so they don't have to know wikitext or HTML to contribute well formatted content. It is our top priority and you can already test it at the English Wikipedia. While we focus on the core functionality, you could write a plugin to extend it, for instance with syntax higlighting, or insertion of video or Wikidata content. There are also many possibilities to increase the types of content supported, including sheet music, poems, timelines…

Skills: HTML / JavaScript / jQuery development is required. A good grasp of UX / Web design will make a difference.

Mentors: James Forrester, Roan Kattouw, Trevor Parscal.

Championing i18n
Internationalization (i18n) and localization (L10n) are part of our DNA. The Language team develops features and tools for a huge and diverse community, including 258 Wikipedia projects and 349 MediaWiki localization teams. This is not only about translating texts. Volunteer translators require very specialized tools to support different scripts, input methods, right-to-left languages, grammar...

Below you can find some ideas to help multilinguism and sharing of all the knowledge literally for everybody in their own language.

Tools for mass migration of legacy translated wiki content
The MediaWiki Translate extension has a page translation feature to make the life of translators easier. It allows structured translation of wiki pages separating text strings from formatting or images, and also tracks changes in the source pages (usually in English). You can see it action in this page (click the Edit view). Often, wikis have a lot of legacy content that requires tedious manual conversion to make it translatable. It would be useful to have a tool to facilitate the conversion. You would show the proof of concept in Meta-Wiki, a Wikimedia community looking forward for a project like this.

Skills: PHP, interest in usability and conducting user research.

Mentors: Niklas Laxström, Federico Leva.

jQuery.IME next big release improvements
The JQuery.IME input method editor library is part of the UnversalLanguageSelector extension. It works but after the feedback of the first release we have a good idea of what would need to be done in a next release. The main improvements would be to add an onscreen keyboard feature, support for content editable Divs and better browser compatibility. If you want more, we have more open issues.

Skills: JavaScript, jQuery, CSS, QUnit, browsers.

Mentors: Santhosh Thottingal.

Wikidata features
Wikidata is a free knowledge base that can be read and edited by humans and machines alike. If you understand the difference between plain text and data you will understand that this project is Wikipedia's Game-changer. The conversion from text to Wikidata content fields has started in Wikipedia and sister projects and continues diving deeper, but there is still a lot to do!

The Wikidata team welcomes your suggestions and provides you with some ideas.

Mentors: Wikidata team available. Lydia Pintscher is provisionally acting as proxy.

3rd party client
Currently the Wikidata client is only set up to directly serve data to the Wikimedia projects. The goal of this project is to also allow 3rd party clients to consume Wikidata data in the same way. For example, it is missing propagation of changes to clients out of the Wikimedia cluster, so they would show up in the watchlist and recent changes of the 3rd party MediaWiki sites.

New media types supported in Commons
Wikimedia Commons a database of millions of freely usable media files to which anyone can contribute. The pictures, audio and video files you find in Wikipedia articles are hosted in Commons. Several free media types are already supported but there are more requested by the community, like e.g. X3D for representing 3D computer graphics or KML/KMZ for geographic annotation and visualization. Considerations need to be taken for each format, like security risks or fallback procedures for browsers not supporting these file types.

Skills: PHP at least. Good knowledge of the file type chosen will be more than helpful.

Mentors: Thomas PT and Brian Wolff.

Automatic category redirects
This is one of the oldest and most voted MediaWiki feature requests. MediaWiki has a feature called redirects where one page can redirect to another. However they do not work for categories. In the ideal system, if Category A redirects to B, and someone puts page foo in category A, then the page should show up in category B. If Someone changes Category A to redirect to Category C, all the pages put in category C have to have their links moved from Category A to Category B.

This project would involve several of the "core" components of core MediaWiki including the, the database schema, and class. However it is quite self contained. This project would also be quite beneficial to several wiki projects, especially multilingual projects like Wikimedia Commons.

Skills: PHP. SQL would be helpful.

Mentors: Brian Wolff.

MediaWiki-Bugzilla extension
Mozilla has developed a MediaWiki-Bugzilla extension which allows for read-only inclusion of Bugzilla lists and charts in MediaWiki pages. For example, it is used to provide "Mentored Bugs" sections. It could also be used for basic prioritization, ToDo lists for projects, metrics... This project consists in enhancing this extension by making API calls more robust (i.e. when receiving 1000s of results), allowing more types of charts, providing good test coverage and user documentation.

Skills: PHP, Javascript, JSON, Bugzilla.

Mentors: Brandon Savage (Mozilla), Sam Reed.

Semantic MediaWiki features
Semantic MediaWiki is a lot more than a MediaWiki extension: it is also a full-fledged framework, in conjunction with many spinoff extensions and it has its own user and developer community. Semantic MediaWiki can turn a wiki into a powerful and flexible collaborative database. All data created within SMW can easily be published via the Semantic Web, allowing other systems to use this data seamlessly.

There are more than 500 SMW-based sites, including wiki.creativecommons.org, docs.webplatform.org, wiki.mozilla.org, wiki.laptop.org and wikitech.wikimedia.org.

Allowing 3rd party wiki editors to run more CSS features
The 3rd party CSS extension allows editors to style wiki pages just by editing them with CSS properties. It could be more powerful if we find a good balance between features and security. Currently this extension relies on basic blacklisting functionality in MediaWiki core to prevent cross-site scripting. It would be great if a proper CSS parser was integrated and a set of whitelists implemented.

Additionally, the current implementation uses data URIs and falls back to JavaScript when the browser doesn't support them. It would be a great improvement if the MediaWikiPerformAction (or similar) hook was used to serve the CSS content instead. This would allow the CSS to be more cleanly cached and reduce or eliminate the need for JavaScript and special CSS escaping.

Skills: PHP, CSS, JavaScript, web application security.

Mentors: Rusty Burchfield.

UploadWizard: OSM map embedding
WLM experience tells us that having a map within the Upload Wizard would simplify the flow of the user greatly. Beyond the contest the map could be used for:
 * making lists of "requested pictures" to prompt after upload in the area "Hey, you're nearby, would you like to go and take a photo of that?" (final step)
 * help categorizing images "Your picture looks to have no metadata. Tell us where you took it clicking on this map", also add on the map thing which already has a picture "Is it one of this?" (optional step)

Skills: PHP, Javascript

Mentors: first mentor TBD, co-mentor avaible from WLM-i team


 * I'll help out with this, but possibly as a co-mentor or in an unofficial capacity :) --MarkTraceur (talk) 22:41, 30 April 2013 (UTC)

Search: New Analyzers
WMF has wikis in 287 languages and our search backend only has support for about 30. If you love language, speak an unsupported language, and are willing to program in Java, we need you.
 * Here are the languages our search backend supports:
 * http://www.elasticsearch.org/guide/reference/index-modules/analysis/lang-analyzer/
 * Japanese
 * Polish
 * Here is a list of languages in which WMF has Wikis: Special:SiteMatrix

Skills: Java, Ability to read and write a currently unsupported language

Mentors: User:NEverett (WMF)  

Beyond development
Featured projects that focus on technical activities other than software development.

Research & propose a catalog of extensions
Extensions on mediawiki.org are not very well organized and finding the right extension is often difficult. Listening community members you will hear about better management of extension pages with categorization, ratings on code quality, security, usefulness, ease of use, good visibility for good extensions, “Featured extensions”, better exposure and testing of version compatibility... This project is about doing actual research within our community and out there to come up with a proposal both agreed and feasible. A plan that a development team can just take to start the implementation.

Skills: research, negotiation, fluent English writing. Technical background and knowledge of MediaWiki features and web development features will get you sooner to the actual work.

Mentors: Yury Katkov.

Annotation tool that extracts statements from books and feed them on Wikidata
Wikidata is a free knowledge base that can be read and edited by humans and machines alike. If you understand the difference between plain text and data you will understand that this project is Wikipedia's Game-changer. The conversion from text to Wikidata content fields has started in Wikipedia and sister projects and continues diving deeper, but there is still a lot to do!

Now think about this: you are at home, reading and studying for pleasiure, or an assignment, or for your PhD thesis. When you study, you engage with the text, and you often annotate and take notes. What about a tool that would let you share important quotes and statements to Wikidata?

A statement in Wikidata is often a simple subject - predicate - object, plus a source. Many, many facts, in the books you read, can be represented in this structure. We an think of a way to share them.

A client-side browser plugin or script or app that would take some highlighted text, offering you a GUI to fix up the statement and source, and then feed it into Wikidata.

We could unveil a brand-new world of sharing and collaborating, directly from you reading.

Possible projects: Mentors: Aubrey is available for mentorship, paired with a technical expert.
 * Pundit. http://www.thepund.it/ (the team is aware of Wikidata and willing to collaborate).
 * Annotator https://github.com/okfn/annotator,

Google Books > Internet Archive > Commons upload cycle
Wikisources all around the world use heavily GB digitizations for transcription and proofreading. As GB provides just the PDF, the usual cycle is:
 * 1) go to Google Books and look for a book
 * 2) check if the book is already in IA
 * 3) if it's not, upload it there
 * 4) get the djvu from IA
 * 5) upload it on Commons
 * 6) use it on Wikisource

For point 4, we have this awesome tool: https://toolserver.org/~tpt/iaUploadBot/step1.php What we miss right now is a tool for point 2.1, that would serve many other users outside the Wikimedia movement too. Eventually, we could think of a bot/script which would do all the work altogether, notifying the user when their help is needed (eg metadata polishing, Commons categories, etc.) Mentors: Aubrey is available for "design" mentorship, paired with a technical expert. We can maybe ask help from a IA expert.



Work on outstanding Parsoid bugs and/or add features
Parsoid is an attempt at bringing some sanity to the world of Wikitext. Whenever you edit a wiki page, on this site for example, a PHP script runs through the page multiple times to come up with the new HTML that it generates. The Parsoid project is a single-pass design, which hopefully makes for a much speedier, and reliable, parser.

But we definitely need your help. Learn more about the complexities of Wikitext parsing, and help push forward the new VisualEditor project, by adding things to the new C++ parser, and making things generally work better.

Things you might need to know, but aren't required to: C++, HTML5, node.js, wiki syntax, parser design.

Contact MarkTraceur (talk) 00:15, 15 November 2012 (UTC) for more information, or just check out the project page.

Triaging bug reports
Wikimedia receives many reports about code mistakes (so-called "bugs") and enhancement/feature requests in the public database located at Bugzilla. Some need to be put into the right baskets so developers can find them and some miss enough information or are not in a good shape to be useful. This process is called Triaging. Triaging helps users/reporters, developers, maintainers, and release management to save time and keep an overview which problems are important. You would work with Wikimedia's bugwrangler.

Some helpful characteristics (these are no strict requirements though) probably include: Common sense and structured approach to problems (finding and asking the right questions), likes to test/reproduce weird things in dark dusty corners of software applications, loves details without being pedantic, is well-organized when it comes to sorting and prioritizing large amounts of (bug)mail, is interested in the organization of large projects (many stakeholders, many subprojects), basic understanding of code concepts in general.

For more information, please read the Bug management documentation on our wiki (especially the Triage Guide), "Why everyone needs a bugmaster" and give triaging reports in Wikimedia a try! --Malyacko (talk) 13:34, 20 November 2012 (UTC)

= Raw projects =

Make Wiktionary definitions available via the dict protocol
The dict protocol (RFC 2229) is a widely used protocol for looking up definitions over the Internet. We'd like to make Wiktionary definitions available for users. Doing that using the dict protocol would help drive the use and usefulness of Wiktionary, as well.

Possible users:
 * Tablet readers often have dictionary lookup included.
 * Students writing papers would have access to a large corpus of words.
 * Mobile applications for Wiktionary would be less tied to MediaWiki itself.

MediaWiki Development
If you're a programmer, we have lots of things for you to do. (To do: copy some relevant ideas from http://socialcoding4good.org/organizations/wikimedia )

Article evolution playback tool idea
Minimal idea: a gadget or script that automates hitting the "newer" link when viewing the old revisions of a MediaWiki article. Need to be able to pause. This would be educational and would be great to use at workshops or presentations to show how Wikipedia actually works.

Purposes:
 * curiosity
 * looking up an edit war
 * finding deleted content

Additional feature:
 * Marking of rollbacks and reverts so they can easily be spotted.
 * The vandalism would usually only flash by while the nice versions of the page would last longer.

Difficulties:
 * how to deal with time? Equal amount of time between each diff, or proportional to edit times?  The time could be handled in several ways and it would be nice if the user could select which one to use. Radiobutton for eqaul time or proportional. Input field for total length of show, default to 15 seconds (or perhaps even 1 second per made edit on the article).

Additional features that would be nice:
 * seeing authors' names
 * slider, like Etherpad

(Project idea suggested by Jan Ainali. No mentors currently available.)


 * The approved project m:Grants:IEG/Replay_Edits seems to cover this idea?--Qgil (talk) 22:01, 29 March 2013 (UTC)
 * Both m:Grants:IEG/Replay_Edits and the above idea have a lot of similarities lets collaborate and make it happen --Jeph paul (talk) 08:35, 31 March 2013 (UTC)
 * Another related concept is IBM's History Flow and it's descendant WikiHistoryFlow (which produces an SVG). - Amgine (talk) 03:59, 19 April 2013 (UTC)
 * A demo of the tool I'm building.--Jeph paul (talk) 16:37, 19 August 2013 (UTC)

[generic] Write useful Lua modules
We're in the process of moving towards a future where complex programming tasks usually dealt with by complex templates are handled in Lua, a friendly scripting language. To that end, it would be great to have someone who spent a lot of time writing useful scripts in Lua and testing them, either on local wikis or on MediaWiki.org.

Things you might need to know, but aren't required to: Lua, advanced wiki syntax (for translating old templates)

This project idea contributed by MarkTraceur (talk) 20:55, 14 November 2012 (UTC) (a mentor)


 * Some useful modules (from what I can think of):
 * Module for listing and searching a page's history and logs, e.g., retrieve revision information, search for all revisions by an author, get all protection logs, etc.
 * Function/module for performing an internal API call and retrieving the results.
 * All I got for now. Parent5446 (talk) 18:23, 18 March 2013 (UTC)

Improving the skinning experience
Research how to make the development of skins for MediaWiki easier. Many users complain about the lack of modern skins for MediaWiki and about having a hard time with skin development and maintenance. Often sys admins keep old versions of MediaWiki due to incompatibility of their skins, which introduces security issues and prevents them from using new features. However, little effort was done to research the exact problem points. The project could include improving skinning documentation,organizing training sprints/sessions, talking to users to identify problems, researching skinning practices in other open source platforms and suggesting an action plan to improve the skinning experience.

Add low-resolution styles for Vector
Vector is nice for large screens with a lot of space; however, it quickly degrades on smaller resolutions (such as approx. 800 px width, which is common on tablets and smartphones, and sometimes can be seen on desktops too, possibly if the user has multiple browser windows open side-by-side ) and becomes completely unusable on resolutions around 320 px (common in "dumb" mobile phones, a.k.a. feature phones, which are extremely popular in second- and third-world countries). While the MobileFrontend extension has been created to alleviate this issue for Wikimedia wikis, it lacks many crucial features (such as page editing) and may not be appropriate for third-parties.

Implementing separate (or additional) stylesheets for such resolutions using the CSS Media Queries feature, and potentially some cleanup for the existing CSS, seems like a nice project for a few weeks' work.

Extensions
Check Manual:Extensions and extension requests in Bugzilla.

[generic] Create an extension
Creating extensions to MediaWiki is a great way to make it better. It contributes something new and cool to the community, and the Wikimedia sites (including Wikipedia!) might even decide to deploy your software, if it's really neat.

If you have some great idea for a feature that MediaWiki doesn't have, an extension is almost surely the way to work on it. This is a very open-ended project idea. First get an opinion of MediaWiki developers to make sure that the idea makes sense.

If you need ideas, extension requests can be found here and here.

Things you might need to know, depending on the extension you want to write: PHP, JavaScript, jQuery, wiki syntax.

This project idea contributed by MarkTraceur (talk) 22:29, 13 November 2012 (UTC) (a mentor)

Work on backlogged bugs in Extension:UploadWizard
The UploadWizard project is an extension to MediaWiki that focuses on enabling users to more easily upload between 3 and 50 photos at a time. The project is primarily deployed on Commons, and is written mostly in JavaScript.

Things we could work on: Making the interface (even) more friendly, fixing bugs, adding integration with other media-sharing platforms (Flickr was just added, but MediaGoblin or raw URL might be useful), and much much more.

Things you might need to know (but of course aren't required to): JavaScript, jQuery

This project idea contributed by MarkTraceur (talk) 22:29, 13 November 2012 (UTC) (a mentor)

An easy way to share wiki content on social media services
Wikipedia, as well as other wikis based on MediaWiki, provide an easy way to accumulate and document knowledge, but it is difficult to share it on social media. According to https://strategy.wikimedia.org/wiki/Product_Whitepaper 84% of Wikimedia users were Facebook users as well in 2010, with the portion incresing from previous years. The situation is probably similar with other social media sites. It only makes sense to have an effective "bridge" between MediaWiki and popular social media site. More details here.

Some previous work you can use as a base, improve, or learn from:

Extension:Widgets

Extension:WidgetsFramework - experimental extension

Extension:AddThis

Extension:Facebook - just Facebook

Extension:WikiShare - unstable version, seems like it's not worked on any more

Write an extension to support XML Sitemaps without using command line
Sitemaps are files that make it more efficient for search engine robots (like googlebot) to crawl a website (so long as the bot supports the sitemap protocol.) Manual:GenerateSitemap.php describes the common way of generating XML Sitemaps. Write an extension, which allows users to generate Sitemaps on a given schedule without using command line.

Extension:OEmbedProvider
Finish Extension:OEmbedProvider, as proposed here. See also Bug 43436 - Implement Twitter Cards

Leap Motion integration with MediaWiki
MediaWiki has a wide user base and a lot of users today prefer touch based interfaces. Gesture based interface are friendly and the latest trend. Leap Motion provides controllers that can recognize gestures. It can be integrated with MediaWiki products like Wikisource. As an example, this would make it more friendly for users to flip through pages in a book. Another advantage of using gesture recognition would be to include turning through multiple chapters or pages at a time by identifying the depth of user's finger's motion.

It would also be helpful for flipping through images in Wikimedia Commons.

(Project idea suggested by Aarti Dwivedi).

Work on RefToolbar
The en:Wikipedia:RefToolbar/2.0 extension is incredibly useful, especially for new editors but also for experienced editors (I use it every day, and I've got a few miles under my belt!). But it suffers from bugs and problems, and there are a lot of improvements that could be made. For instance: adding additional reference types, adding fields for multiple authors, tool-tip help guidance, etc. I also suspect it will need an upgrade to match Lua conversions of common cite templates. Also, I don't think this is in wide deployment on other wikis, so translation/deployment could be a project. Looking at the talk page, there are a couple people starting to work on this but serious development isn't happening (so I'm not sure who would mentor this) but the code was recently made accessible. At any rate, it is an extension that really needs some work and where improvements would have immediate benefit for many editors.

Project idea contributed by Phoebe (talk) 23:23, 22 March 2013 (UTC) [n.b.: I can't mentor on the tech side, but can give guidance on the ins and outs of various citation formats in the real world & how cite templates are used on WP].

See

Squash bugs and add features to Extension:Education_Program
The Education Program extension lets users organize classroom editing assignments, and can also be used to organize and track participation in outreach events such as edit-a-thons. It's in use on English Wikipedia and a growing number of other wikis. There are lots of bugs both small and large, as well as some interesting features that could be added.
 * bugs
 * features wishlist and ideas

Sage Ross (not a developer, but familiar with extension code and the use of it, as well as the basics of MediaWiki development process) can provide some mentorship.

Global, better URL to citation conversion functionality
Suppose, in Wikipedia, all that needed to be done to generate a perfect citation was to provide a URL? That would be a tremendous step toward getting a much higher percentage of text in Wikipedia articles to be supported by inline citations.

There are already expanders (for the English Wikipedia, at least) that will convert an ISBN, DOI, or PMID, supplied by an editor, into a full, correct citation (footnote). These are in the process of being incorporated into the reference dialog of the VisualEditor extension, making it almost trivial (two clicks, paste, two clicks) to insert a reference.

For web pages, however, the existing functionality seems to be limited to a Firefox add-on. Its limits, besides the obvious requirement to use that browser (and to install the add-on), include an inability to extract the author and date from even the most standard pages (e.g., New York Times), and the lack of integration with MediaWiki.

For a similar approach, using a different plug-in/program, see this Wikipedia page about Zotero.

A full URL-to-citation engine would use the existing Cite4Wiki (Firefox add-on) code, perhaps, plus (unless these exist elsewhere) source-specific parameter specifications. For example, the NYT uses "" for its author information; that format would be known by the engine (via a specifications database). Each Wikipedia community would be responsible for coding these (except for a small starter set, as examples), in the way that communities are responsible for TemplateData for the new VisualEditor extension.

(Project idea suggested by John Broughton.)

Wikimedia Commons / multimedia
Sébastien Santoro (Dereckson) can mentor these projects idea.

Support for text/syntax/markup driven or WYSIWYG editable charts, diagrams, graphs, flowcharts etc.
Resucitate Extension:WikiTeX and fold Extension:WikiTex into it.

VisualEditor support for EasyTimeline
Also mentioned at.

Multilingual, usable and effective captchas
This project is very ambitious and challenging. Current CAPTCHAs are mostly broken, and still they are important to guard web sites like Wikipedia from a lot of spam. Risk of failure is high, but when it succeeds, the rewards may be huge.

This project has a large research, design and user test component. The student will research and assess ways to use different CAPTCHA options, designed for multilingualism, to identify a more effective CAPTCHA than the current implementation used by Wikimedia. The student will create an implementation for use in MediaWiki of the identified CAPTCHA method. See related bug 32695. Some prototypes have been designed a while ago.

Mentors: Siebrand Mazeland and Pau Giner

Skills: Design, JavaScript and PHP.

MediaWiki LocalisationUpdate for all
There is the LocalisationUpdate extension. But only few people use it. It is slow and needs a special configuration with cron. If we could integrate it into core, make it fast enough so that cron would not be needed it would allow a lot of third parties to enjoy the blazingly fast localisation updates (under 36 hours) that Wikimedia projects currently have. To make it fast enough, it is likely that a separate service needs to be implemented. It could be standalone or part of some MediaWiki instance. It should be secure and allow querying only needed data.

Mentors: Niklas Laxström

Skills: PHP, web protocols and security

Multilingual SemanticMediaWiki
Semantic MediaWiki would benefit from being multilingual-capable out of the box. We could integrate it with the Translate extension. This can be done in some isolate steps. Some of the steps could be:


 * Fix the issues that prevent full localisation of semantic forms.
 * Enhance Special:CreateForm and friends to create forms that are already i18ned with placeholders and message group for Translate extension.
 * Make it possible to define translation for properties and create a message group for Translate extension
 * There are lot of places where properties are displayed: many special pages, queries, property pages. Some thinking is required to find out a sensible way to handle translations on all these places.

Skills: PHP and web frontend, has used SemanticMediaWiki and SemanticForms is a plus.

Mentors: Niklas Laxström (with yet unknown co-mentor from SMW).

Improve Extension:WebFonts or Extension:UniversalLanguageSelector for Chinese (or CJK) wikis
Chinese uses too many characters, and many are rarely used so it's not often installed on readers' systems. However including all of them in the font file makes it huge, so we may want to tailor the font file for every page based on characters used on that page.

As of writing, there isn't any "good" enough free font which includes all Chinese characters in Unicode and the "wiki" concept itself encourages collaborative content creation, so it would be nice to invite user to create a glyph for it when the system sees a character without existing data (remember we need free contents). en:WenQuanYi and glyphwiki.org already have some online glyph creators which can be useful for us.

Maybe we can donate glyphs created by wiki users to other projects, but we have to make sure our data meet their quality standards...

Skills: PHP, Web frontend, Font creation and management. Some knowledge of CJK characters can be a plus.

Contributed by: User:Liangent

Merge proofread text back into Djvu files
Wikisource, the free library, has an enormous collection of Djvu files and proofread texts based on those scans. However, while the DjVu files contain a text layer, this text is the original computer generated (OCR) text and not the volunteer-proofread text. There is some previous work about merging the proofread text as a blob into pages, and also about finding similar words to be used as anchors for text re-mapping. The idea is to create an export tool that will get word positions and confidence levels using Tesseract and then re-map the text layer back into the DjVu file. If possible, word coordinates should be kept.
 * Project proposed by Micru. I have found an external mentor that could give a hand on Tesseract, now I'm looking for a mentor that would provide assistance on Mediawiki.
 * Aubrey can be a mentor providing assistance regarding Wikisource, and some past history of this issue. Not much, but glad to help if needed.

Mobile reporting platform
Wikinews encourages its journalist to engage in original reporting. Timeliness of contributing it very important, and being able to do reporting from the field can be essential for larger events such the Paralympic Games, World Championships, Olympic Games, and Commonwealth Games. Creating a reporting toolkit that could allow reporting from a tablet device would be extremely useful. Some of these tasks are already built into other projects, such as commons. Tasks that would be nice for a mobile reporting tool for reporters to do (though not all required but would be nice to have):
 * Recording audio files in ogg or converting audio files to an ogg format. Being able to chose whether to upload these files to a local Wikinews project or to Commons under a compatible license.
 * Transcription of audio files into text format.
 * Recording video files in ogv or converting video files to an ogv format. Being able to chose whether to upload these files to a local Wikinews project or to Commons under a compatible license.
 * Being able to upload pictures to a local Wikinews project or to Commons under a compatible license.  Automatically create gallery code with the Wikinews photographer credited in compliance with local Wikinews policies for photo essays.
 * Being able to type notes that can be automatically shared on the talk page of the associated Wikinews article being developed.
 * Being able to import e-mails that are used for reporting verification in PDF format to the program that can be uploaded locally to Wikinews or can be sent to scoop@wikinewsie.org. Have an automatic message posted to the talk page of the associated Wikinews article being developed explaining were the verifying information can be found.
 * Allowing reporters to sort audio, video, image files, typed reporter notes, e-mailed information by reporting event for ease in use.
 * Automate part of the process for creating an article on Wikinews by pulling in the default draft template, autogenerating category for the reporter, putting in the original reporting template, pulling in the location from the device to say where the reporting is being submitted from, then querying reporter about topic for appropriate infobox and categories for the article.

Laura Hale and pi zero, both on the provisional board of The Wikinewsie Group would be keen to act as mentors for how to implement this from a community perspective. Some limited technical assistance may be available. The tool may also be useful for educational outreach programs and some Commons uploading activities.

Mobile viewing application
A mobile web application would be nice to have for Wikinews that could be downloaded from Apple's App Store or Android's App Store.

Laura Hale and pi zero, both on the provisional board of The Wikinewsie Group would be keen to act as mentors for how to implement this from a community perspective. Some limited technical assistance may be available. The tool may also be useful for educational outreach programs and some Commons uploading activities.

Automated news translation
There have been several discussions about implementing machine assisted translation tools on Wikipedia. Wikinews would strongly benefit from this too, because it would make reporting more cost effective by bringing the total number of stories generated to a higher number. Most projects have their own review process before publishing and their own local style guides. Some of the localization information is available on English Wikinews. There is no preference for the technical backend of how automated news translation is done, nor any specific requirements for the amount of human assistance needed to insure article publication. The community is willing to discuss any potential experiments in implementation.

Laura Hale and pi zero, both on the provisional board of The Wikinewsie Group would be keen to act as mentors for how to implement this from a community perspective. Some limited technical assistance may be available. The tool may also be useful for educational outreach programs and some Commons uploading activities.

Implementing volunteer testing tracking framework
Wikimedia frequently deploys changes to software. It is always useful to test features as early and thoroughly before deployment. Currently Wikimedia doesn't have a proper process to communicate with volunteer testers and invite them to test features. Sometimes the wikitech-ambassadors list is used, sometimes new features run in beta and volunteers are invited to write up their experiences on a talk page somewhere, but very frequently features are not announced at all. The situation is complicated by the fact that the different Wikimedia sites work in almost 300 languages with different fonts, different string lenghts, different templates, different extensions, different CSS etc.

One way to solve this is to develop some tools and procedures to communicate with prospective volunteer testers and to collect feedback from them, both positive and negative. It can be a simple form that says: feature x, languages XX, OK/FAIL. See an example from Fedora here: QA-L10N:nautilus test day. In Fedora, the technical side of things is actually just a MediaWiki table. We could just use that, or we could do something even better: maybe a MediaWiki extension, or maybe even some non-MediaWiki-based technology.

In any case, an easy-to-understand workflow would be very important, even if the technical tools are good, and writing these tools and procedures would be a very useful contribution to the MediaWiki developers' and users' community. --Amir E. Aharoni (talk) 19:36, 14 November 2012 (UTC)

System documentation integrated in source code
It would be really nice if inline comments, README files, and special documentation files could exist in the source code but be exported into a formatted, navigable system (maybe wiki pages or maybe something else). It could be something like doxygen, accept better and orientated to admins and not developers. Of course it should integrate with mediawiki.org and https://doc.wikimedia.org.

The idea would be that one could:
 * Keep documentation close to the code and thus far more up to date
 * Even enforce documentation updates to it with new commits sometimes
 * Reduce the tedium of making documentation by using minimal markup to specify tables, lists, hierarchy, and so on, and let a tool deal with generating the html (or wikitext). This could allow for a more consistent appearance to documentation.
 * When things are removed from the code (along with the docs in the repo), if mw.org pages are used, they can be tagged with warning box and be placed in maintenance category.

Proposed by Aaron Schulz.

Ranking articles by Pageviews for Wikiprojects and Task Forces in Languages other than English
Currently we have an amazing tool which every month determine what pages are most viewed for a Wikiproject and then provides a sum of the pageviews for all articles within that project. An example of the output for WikiProject Medicine in English.

The problems is that this tool only exists in English and is running on toolserver rather than Wikimedia Labs. So while we know what people are looking at in English, and this helps editors determine what articles to work on, other languages do not have this ability.

Additionally we are do not know if the topics people look up in English are the same as those they look up in other languages. In the subject area of medicine this could be the basis of a great academic paper and I would be happy to share authorship with those who help to build these tools.

A couple of steps are needed to solve this problem:
 * 1) For each article within a Wikiproject in English, take the interlanguage links stored at wikidata, and tag the corresponding article in the target language
 * 2) Figure out how to get Mr. Z's tool to work in other languages . He supposedly is working on it and I am not entire clear if he is willing to have help. Another tool that could potentially be adapted to generate the data is already on Labs

James Heilman (talk) 21:13, 14 September 2013 (UTC)