Outreachy/Round 14

About
Wikimedia is participating as a mentoring organization for Outreachy. Outreachy is a progam that connects people from groups underrepresented in free and open source software in a three-month, full-time internship and runs two editions every year.

Learn more about our motivation and goals to run this program: FLOSS internships programs as catalysts for richer community collaboration.

This year's program will run May - August 2017. To learn about the full program timeline, visit the official website.

All major projects of Wikimedia are developed with help from contributors from all around the world using MediaWiki. MediaWiki is the software that powers Wikipedia, its sister projects and thousands of wikis all over the world. MediaWiki runs on most operating systems, is written in PHP, primarily uses the MySQL and MariaDB database servers and uses jQuery as the client JavaScript library. Besides software development, there are various ways through which one could contribute to our community: Design, Documentation, Translation, Testing, etc. Learn more here.

Recommended Next Steps

 * 1) Look at the Outreachy website to get an overview of the program.
 * 2) Learn how to have a successful project in the context of an outreach program with Wikimedia.
 * 3) Get a brief overview of projects available under Project Ideas section on this page. Choose a project that you really like and best fits your skill set. Express your interest in working on the project by commenting on the corresponding task on Phabricator. Post in the task comments, ask intelligent and explicit questions ("Could you tell me more about this?" is a bad example), do your research thoroughly, don't expect spoon-feeding. That's the recipe for a perfect intern!
 * 4) If you are going to work on a coding-related project, learn basic skills required for contributing to the MediaWiki development.
 * 5) Read the guidelines to prepare an Outreachy proposal. The program expects its applications to fill out answers to all questions in its application template in their proposal. The applicant is expected to submit the completed project proposal to the Outreachy application system including a link to their public proposal in Wikimedia Phabricator. Examples of some really good proposals that were accepted for the previous round:
 * 6) * https://phabricator.wikimedia.org/T148287
 * 7) * https://phabricator.wikimedia.org/T147727
 * 8) * https://phabricator.wikimedia.org/T148074
 * 9) If you would like to work on your own project idea, communicate with relevant developers first.

Contact

 * Trouble connecting with mentors of projects you are interested in applying to? Got application or program-specific question, come and talk to us in the IRC channel #wikimedia-devrel or reach out to the organization admins Srishti Sethi ssethi[at]wikimedia[dot]org or Anna Liao (aliao22[at]gmail[dot]com).
 * For a project-related question, either communicate with mentors on the corresponding task in Phabricator or reach out to them in their project's IRC channel.
 * Mailing list for program specific discussion: wikitech-l@lists.wikimedia.org.

Write a Zotero translator and document process for creating new Zotero translator and getting it live in production
Citoid is a service that allows people to easily add references on Wikipedias. It relies heavily on Zotero's translation-server, which in turn uses various translators to get citation metadata from specific pages. Watch the related tech talk here. However, it would be nice to have a page on MediaWiki that details how to do this with citoid specifically in mind. Learn how to write a Zotero translator here. However, this documentation is only available for writing translators for the browser plug-in, not translation-server. Translators often work both in the browser and translation server, but for citoid's purposes it is necessary for any new translators to work in translation-server, so more targeted documentation specifically for citoid would be nice. If relevant, adding/fixing documentation on Zotero's wiki as well as on MediaWiki can be part of the scope of the project. Writing a new translator for Zotero's translation server is also within the scope of the project as part of the process of documenting it. Translators are in Javascript. Familiarity with HTML is helpful as translators are essentially web scrapers. There are many requested translators on the translator repo so there are lots to choose from.

Getting Started

Follow the instructions to install Zotero's translation server: https://github.com/zotero/translation-server

Skills Required Javascript, Documentation

Tags VisualEditor, Citoid

Link https://phabricator.wikimedia.org/T115158

Mentors Marielle Volz, Czar

Provide some love to the quiz extension
The Quiz extension was created by a volunteer and is currently installed on several WMF projects, such as Wikiversity. However, it is not under active development and there are a number of reported bugs as well as requested features. There are a number of tasks that should be done to improve the extension: Getting Started
 * Import all the bugs reported on the wiki page to the phabricator board. Here is an example.
 * Re-check and triage all of the old bugs
 * Fix any high priority bugs
 * Implement new desired features, for example T148613

Install mediawiki locally. It is easiest (often) to use vagrant for this. Quiz is not available as a role in vagrant, so follow these directions to manually add lines to LocalSettings.php in vagrant, and include the line require_once("$IP/extensions/Quiz/Quiz.php"); You can test that the extension is working by adding a sample quiz to your test wiki in wikitext. The quiz syntax is well documented here.

You can find the quiz extension in the vagrant repository by navigating to mediawiki/extensions/Quiz. If you haven't already, you will need to set up git, gerrit, and git-review, and install a Gerrit hook to begin submitting commits to the Quiz extension.

Skills Required PHP

Tags MediaWiki-extensions-quiz

Link https://phabricator.wikimedia.org/T148969

Mentors Marielle Volz, Sam Reed

Localize one or more major WMF software products related to new editor retention to hu.wikipedia
Like many other language versions, Hungarian Wikipedia is in a decline, driven by the inability to attract new editors. The Wikimedia Foundation and the movement produced various software to address that issue, but a significant part of that did not reach local communities because the last-mile effort of localization did not happen. ("Localization" is used in a wide sense here, including software localization on translatewiki.net, but also writing local documentation, adapting local gadgets, advertize new features to editors etc.). The primary goal of this project would be to improve that situation by improving the localization of some major software products. The secondary goal is to make such localization easier for other wikis easier by documenting the process and its learnings. The exact selection of software features is up for discussion and might depend on the candidate's skills and interests; some suggestions: There is rough consensus for most of these changes (see here for some past discussion).
 * VisualEditor: finish interface translation, translate and adapt documentation, identify most used templates and add TemplateData (possibly write software tool for converting hu.wikipedia's old template documentation system), enable Citoid, write Zotero plugins for major Hungarian information sources, convert the old CharInsert-based character map, make sure all custom edit buttons/tools for which it makes sense are ported, review gadgets on large wikis and import the most useful ones, update wiki help pages, popularize VisualEditor (especially amongst mentors) and forward feedback to Phabricator
 * Flow: finish interface translation, translate and adapt documentation, organize and set up a trial (see T119365), collect feedback, maybe help with adapting local bots
 * ORES: organize a workforce to finish the "damaging" campaign and possibly do other campaigns; if really ambitious, modify FlaggedRevs to use ORES scores for auto-reviewing
 * build a local version of the teahouse

Skills Required Tags Localization
 * Has to speak Hungarian
 * Community Engagement (ideally some level of familiarity with the Hungarian editor community)
 * Coding skills: Javascript would be the most useful; Python (esp. Pywikibot), Lua, PHP, MediaWiki templating skills could also be put to good use. Coding skills are optional - it's also possible to find enough work by picking non-coding related subtasks which require no programming.

Link https://phabricator.wikimedia.org/T147618

Mentors Gergő Tisza

Translation outreach: User guides on MediaWiki.org
The Wikimedia movement has a lot of technical user guides and other technical documentation in English, relevant for users of all languages, hosted on MediaWiki.org. This is usually translatable and rarely translated, at least not into more than a few languages, leaving many Wikimedians without documentation of their software in languages they can comfortably read. The Wikimedia movement is a volunteer movement: we edit and translate (and to a fairly large degree, do technical development and technical documentation) in our spare time, but the roads to becoming a translator are difficult to find, and it's difficult to get engaged in the movement as a translator rather than as an editor who sooner or later ends up helping out with translation. Some tasks would be: Resources Skills Required
 * Identify places and communities where it'd make sense to reach out to potential translators
 * Identify ways to do it
 * Test them
 * Make sure someone else can continue the work
 * Introduction to Wikimedia translations
 * Short introduction for translators who are new to the Wikimedia movement
 * Translation strategy

Localization of technical documentation

Tags Localization

Link https://phabricator.wikimedia.org/T158296

Mentors Johan Jönsson, Benoît Evellin

Allow Programs & Events Dashboard to make automatic edits on connected wikis
The Programs & Events Dashboard — outreachdashboard.wmflabs.org — supports coordinated editing programs, like edit-a-thons and the Wikipedia Education Program — across many languages and Wikimedia projects. The Wiki Education Foundation Dashboard — dashboard.wikiedu.org — uses OAuth to make automatic edits on English Wikipedia, adding templates to user pages and article talk pages as well as creating and updating mirrored wiki versions of each course page. For example: https://en.wikipedia.org/wiki/Wikipedia:Wiki_Ed/University_of_Guelph/Pet_Nutrition_%28Fall_2016%29

These wiki editing features would be useful for Programs & Events Dashboard as well, especially for Wikipedia Education Programs that want to move from deprecated EducationProgram extension to the dashboard as the basis for organizing Wikipedia classroom projects. To do that, we'll need to extend the dashboard system to: Resources Skills Required Text processing / Regular expressions, Mediawiki markup and templates, Ruby on Rails, Object-oriented design, usage of the Mediawiki API
 * Enable wiki edits on a per-wiki basis
 * Design a standard form for working with templates on a per-wiki basis
 * Identifying which types of edits can be applied to any wiki and which can't
 * Design a workflow for enabling wiki edits on new wikis
 * Setup a development environment: https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/docs/setup.md
 * Talk with us: #wikimedia-ed on Freenode IRC
 * Some possible micro-contributions: https://github.com/WikiEducationFoundation/WikiEduDashboard/issues?q=is%3Aissue+is%3Aopen+label%3A%22newcomer+friendly%22

Tags Education Program Dashboard

Link https://phabricator.wikimedia.org/T158678

Mentors Ragesoss, Capt_Swing

Add automatic article feedback feature to Wiki Ed Dashboard / Programs & Events Dashboard
The Wiki Ed Dashboard / Programs & Events Dashboard is a Ruby on Rails + Javascript application that helps people organize groups of newcomers to contribute to Wikipedia. Wikimedia's artificial intelligence projects, specifically ORES (Objective Revision Evaluation Service), have the potential to be used to provide specific useful feedback to newcomers about how they can improve existing Wikipedia articles or article drafts they are working on.

Here's an example of the data we have available for every revision in the history of an article: https://ores.wikimedia.org/v2/scores/enwiki/wp10/26734?features

Let's try this out and see if it can be turned into a useful tool for newcomers: Resources Skills Required Javascript, Ruby on Rails, Object-oriented design, User interface design, Mediawiki markup, Wikipedia editing experience, Machine learning (to understand, and possibly help improve or identify areas for improvement in, ORES)
 * Use ORES data imported into the Dashboard to identify specific aspects of articles that can be improved.
 * Create messages explaining to users how to improve their articles
 * Design and implement a user interface for showing the messages
 * Measure the effectiveness of these messages in prompting users to improve their articles
 * Conduct user tests to identify ways of improving the feedback, and improve it
 * Setup a development environment: https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/docs/setup.md
 * Talk with us: #wikimedia-ed on Freenode IRC
 * Some possible micro-contributions: https://github.com/WikiEducationFoundation/WikiEduDashboard/issues?q=is%3Aissue+is%3Aopen+label%3A%22newcomer+friendly%22

Tags Education Program Dashboard

Link https://phabricator.wikimedia.org/T158679

Mentors Ragesoss, Capt_Swing

Add a spreadsheet interface for modifying multiple pages to the Page Forms extension
The Page Forms extension allows for editing only one page at a time. Normally this is fine, but in some cases an administrator or "power user" may want to change many pages at the same time - for instance, if there has been a change to the data structure, like a parameter/field getting added to a template.

What is needed is a new "special page", defined by Page Forms, that displays a spreadsheet interface for editing many pages, where each row represents a single template call and each column represents a template parameter, i.e. form field. There may be more than one call to a template on the same page, so this interface would need to handle that case as well. This interface should most likely be implemented using the jsGrid library, which thankfully is already in use by Page Forms for other purposes: http://js-grid.com

The steps of such a project may look something like: Skills Required PHP, JavaScript
 * Make a basic "minimum viable product" special page that lets the user edit all the calls to any specific template, using a spreadsheet interface, with a text entry for each value.
 * Add support for pagination, for large data sets.
 * Add support for adding new pages via the same interface.
 * Use other Page Forms code to get the ideal input type (text, dropdown, checkbox etc.) for each template parameter, and display that in the spreadsheet.
 * Add support for additional input types that jsGrid does not handle by default - the most important being dates and two autocompletion-based inputs, "combobox" and "tokens". This part should be a fun challenge for anyone who enjoys working with JavaScript and jQuery.
 * Optionally provide support for renaming pages from within the interface.

Tags MediaWiki-extensions-Page_Forms

Link https://phabricator.wikimedia.org/T63989

Mentors Yaron_Koren, TBD

Single image batch upload
Currently when somebody does a batch upload (uploading a lot of images which were released by an archive/museum (GLAM)) all images get uploaded and lots of those might not be used or not that useful. However uploading released images one by one wastes a lot of time. A solution to this would be to provide the metadata-mapping which makes an upload possible and a framework which using these mappings can be used to upload a single (or a small subset) of images from a GLAM. In the best final version this would allow a GLAM to provide an "upload to Wikimedia Commons" button on their website. The task at hand here is to build this framework. For each GLAM a separate metadata mapping is needed, you don't have to make these: I will provide/create such a mapping for a Dutch archive (Nationaal Archief) or if needed from an English archive. However we'll have to discuss a good way these mappings can be added/maintained. The most suitable place for this to land is likely https://tools.wmflabs.org/. For authentication we could make use of OAuth. More thorough description of the idea can be found at:  https://commons.wikimedia.org/wiki/User:Basvb/Ideas/Single_Image_Batch_Upload

Skills Required Combination of frontend and backend (preferrably python backend)

Tags Wikimedia Commons

Link https://phabricator.wikimedia.org/T138464

Mentors Basvb, TBD

Some other ideas
Look through the possible-tech-projects and '' Wishlist 11-30 (needs owner)" and "Wishlist 31-50 (needs owner)" column on the Community-Wishlist-Survey-2016 workboard. Some of them might not be ready to be mentored (for example missing discussion or mentors), but if you show your interest in working on those projects, it's likely that someone from the community would be willing to support you!