Outreachy/Round 6



Wikimedia is participating in the Free and Open Source Outreach Program for Women 2013. Several paid internship positions for 3 months projects are available for women willing to develop open source projects related to Wikimedia or other participant organizations.

Below you have more details specific to the Wikimedia projects and mentors. You can find general information about the program (like deadlines!) in the official site.

About Wikimedia
Wikimedia is a global movement whose mission is to bring free educational content to the world. Through various projects, chapters, and the support structure of the non-profit Wikimedia Foundation, Wikimedia strives to bring about a world in which every single human being can freely share in the sum of all knowledge.

If you are a technical woman then we probably have an activity interesting for you. All our software projects are open and free. You probably know Wikipedia, and there is more. MediaWiki is a powerful wiki engine used by Wikimedia websites and hundreds of projects out there. We also run projects related with server infrastructure, automated testing, mobile, internationalization, user experience... The main programming languages used are PHP, Javascript and HTML/CSS.

Get in touch
If you're interested in participating you can reach to us with questions and suggestions. We are happy to help finding a good project for you!
 * Join the wikitech-l technical mailing list.
 * Drop in on our #mediawiki chat channel.
 * If you prefer, you can contact directly qgil AT wikimedia DOT org (qgil on IRC).

Candidates
Here we track the status of all candidates. You are encouraged to fill in your data as soon as possible, regardless of the status of your applications. We love transparency and we are used to work-in-progress.


 * Place all the relevant information and links about you in your user page.
 * Your microtask must be linked to a bug report.
 * Your project must be linked to a wiki page with all the details.
 * Also, add a section "Support for Outreach Program for Women" in your Talk page. You can ask people to post there their recommendations about the project and yourself.

Microtasks
As part of your application, you'll be making a small contribution to our project. This might be fixing one of our annoying little bugs, writing a summary of a few days on the developers' mailing list, checking whether a bug reported in the bugtracker is reproducible, or something like that. In order to get a task, you'll need to contact one of the mentors and ask for one.

Possible projects


These are some drafts for possible projects, split into categories.

Programming
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 )

Write an extension for pulling files from a git repository
This is a project suggested by the good folks at the W3C. We'd like to write an extension that would accomplish most of the features offered by large pastebin websites, with the added bonus of being able to add code to a wiki page without copying and pasting! This would be really great, especially for MediaWiki.org (this website), where a lot of code examples are copied from existing git repositories. It might also be useful to include an (optional) feature that allowed creating and hosting git repositories on the wiki, but that might be more complicated, or perhaps a different project altogether. But the extension itself would be plenty.

Things you might need to know (but of course aren't required to): Git, PHP, JavaScript, HTML, wiki syntax.

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

This project idea is all dried up! MarkTraceur has done all he can to accommodate the enthusiastic applicants, but please stop sending inquiries about this one, there are simply no more ideas left. Thanks!

Add and polish features in Extension:EtherEditor
This is a project to enable real-time collaborative editing in MediaWiki. It's actually pretty mature now, but it could use some fixing up, especially since it's lain dormant for a few months while User:MarkTraceur was working on other projects! In particular, hunting bugs on the bug tracker and polishing the UI would be very useful, and a great way to learn how to work with MediaWiki extensions.

Things you might need to know (but of course aren't required to): PHP, JavaScript, jQuery, node.js, Etherpad, 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)

Create a VisualEditor module
VisualEditor is a key part of Wikimedia Engineering's work in 2012/13, creating a rich visual editor for all users of MediaWiki so they don't have to know wikitext or HTML. Your creation of a module to bring additional functions to the in-progress would help more potential users make better or richer content. If you have a favourite editor feature that you want VisualEditor to have - video insertion, syntax highlighting for wikitext fly-outs, pulling in arbitrary Wikidata content, whatever! - you could help make it even more useful for everyone.

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

This project idea contributed by Jdforrester (WMF) (talk) 23:59, 13 November 2012 (UTC) (a mentor).

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.

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)

[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. There are also many extensions requests for extensions in the bugtracker, but first get an opinion of MediaWiki developers to make sure that the request makes sense.

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)

[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)

Level up Wikimedia Commons experience proposals
Sébastien Santoro (Dereckson) can mentor these two projects idea.

Allow smoother and easier Wikimedia Commons pictures discovery
Skills: Programming. Design.

[//commons.wikimedia.org Wikimedia Commons] is 14 million media repository, all under a free license or in public domain. This is a common repository used on Wikipedia and other Wikimedia projects and available for any other projects in need of educative or informational pictures.

Previous usability and UI effort were focused on the upload process and image reusing.

This project is to think, design and develop a better interface to browse and discover pictures, from a user perspective. For example, it has been suggested to implement a lightbox system to switch to the next picture in the categories. A part of the project could be to prepare an external website to implement this lightbox and so offer a similar browsing experience than other popular pictures sites. If the interface works well, a second phase could be to integrate it directly to Wikimedia Commons.

Another idea is a view mode allowing to browse a root category (e.g. the cats category or the roses category and to be able to see pictures in this category and also the subcategories). This will satisfy the need "I want a cat photo" or "I want a rose photo" without having to browse a dozen of specialized subcategory. In a second step, we could filter result with available information. If you're interested to implement this approach, your project could be whether:
 * the design and development of the viewer mode, with a focus on the UI and ergonomic browser capability
 * to prepare this second step and identify the most relevant criteria (weight, resolution, taken date, color information, most used files on wikis, images with labels) and analyze cost/benefits to cache these data; prepare a prototype with a subset of 1000 images to help to create a performance model and see how in the future have this information could be available for several millions of pictures.

Build an interwiki notifications framework and implement it for InstantCommons
Skills: Programming. Software architecture.

In January 2010, we introduced a setting to ease the possibility to reuse the Wikimedia Commons content on other MediaWiki installations. This feature is called “InstantCommons”.

The Wikimedia Commons community performs a continuous maintenance on wiki files, renaming and deleting media. We currently have tools to detect if the media are used on Wikimedia projects, and tools to replace automatically the names following a rename operation.

It would be interesting to allow wikis (and 3rd party software) to notify Wikimedia Commons they use pictures through a notification API. It would also be interesting if these wikis can subscribe to notifications, so we can notify them back we’ve made a destructive operation (e.g. rename or delete a media file currently in use on their website), so they can automatically or manually take appropriate measures.

This project is to develop an interwiki notifications framework, ideally also open to 3rd party sites, and to use it to implement it to enhance the InstantCommons feature.

Weekly development summary
It would be great for someone to write a weekly summary of the important patchsets that have been committed or merged into our source control system, either to send to our developers' mailing list or possibly for use in the weekly Signpost newspaper. You would learn to navigate our bugtracker, our mailing list, and our source control viewer and gain an understanding of what's important to the developer and user community. For an example of the kind of activity this would cover, see the GNOME commit digest and the KDE commit digest.

You need to be able to write English prose.

Mentor: Guillaume Paumier.

Feature videos
The best way to get certain kinds of documentation, and to teach newer developers how MediaWiki works, is to interview senior developers about important and hard-to-understand components, and turn those interviews into videos.

You need to be able to write English prose, to communicate easily with spoken English, and to run video editing software on your computer.

Mentor: Sumana Harihareswara.

System administration
You're amazing if you want to help run our huge infrastructure. We have some ideas.

Debianize, puppetize, and deploy Etherpad Lite
Etherpad Lite is a complete overhaul of the old Etherpad system of yore. While great, and free software, Etherpad "Classic" is about 10 times as heavy as Etherpad Lite. We would really love to use the new version as our primary way of collaborating in real-time, but there are a bunch of things that need to be done first. We need to make sure a Debian package is available, so we can run it on our servers. We also need to make sure that we can do proper load balancing on it, which can be complicated with Etherpad Lite. Then, we need to write a Puppet manifest and actually do some deploys of it, to make sure everything goes all right.

Things you might need to know: Puppet, Debian packaging, command line.

This project was suggested by MarkTraceur (talk) 01:42, 14 November 2012 (UTC) (a mentor)

Marketing
Sumana Harihareswara can mentor this project idea.

Find the vendors
The independent consultants and other companies that benefit from customizing and reselling MediaWiki would benefit from cross-pollination, referrals, upstreaming their patches, and recruiting. Can you find those vendors, find out what they need from "upstream" (the developers of MediaWiki core and extensions), and start translating those requests into continuing collaboration?

Things you might need to know: English prose, web research skills.

Help develop design documents for Flow
Flow is a "game changing" project that is currently in the initial design phases.

You will be tasked with taking high-level wire-frame documents and providing mid-level interaction designs and visual treatment mockups.

This project will mentor several skills in a broad context.

Mentor: Brandon Harris

Other
If there are projects that don't fall into any category, this is where they should go. Feel free to add new categories, but if you can't think of a name for a category that would fit your project proposal, put it here!

Documenting noteworthy local templates, gadgets and styles in various projects
In addition to MediaWiki and its extensions, Wikimedia sites run a huge amount of other code: locally developed templates, gadgets and styles. Some of the tools that were developed in the English Wikipedia became full-fledged extensions, for example Wikilove. But there's still a lot of code that runs in some projects, that could be useful to other projects, but is hard to install them elsewhere, because it's hard to port and install them. Some examples: The same goes for templates: some templates are so common and useful on some Wikipedias that users expect them on other MediaWiki installations, too (I can think, for example, of en:Template:Cite web, en:Template:Infobox, en:Template:Lang and a bunch of others). The prevalence of such templates may hint at the features that the users need.
 * The English Wikipedia's Citation toolbar.
 * The Russian Wikipedia's typography improvement tool ("Wikificator").
 * The Portuguese Wikipedia's spelling switcher (could be useful for some languages with different orthographies, such as English, Catalan and others).

Documenting such tools doesn't require the knowledge of a lot of languages. It just requires the ability to talk to local editors, to spot interesting differences in the reading and editing interface, and to find frequently used MediaWiki:*.js pages. --Amir E. Aharoni (talk) 19:22, 14 November 2012 (UTC)

Triaging bug reports
Wikimedia receives many reports about code mistakes (so-called "bugs") and enhancement/feature requests in the public database located at https://bugzilla.wikimedia.org. 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)

Consolidate the Git / Gerrit documentation
With the move from SVN to Git our related documentation has just exploded. See Git, Gerrit, Special:PrefixIndex/Git and Bug 36437 - A strict and correct Git workflow document is needed to get an idea of the mess. What we need is a single landing page pointing to the essential resources and a sensible list of comprehensive and correct pages describing what contributors need to know. This work requires familiarity with Git and Gerrit, although you don't need to be an expert. It's actually more useful to be a tester of the docs and processes yourself. Of course good knowledge of written English is required. We are looking for the right mentor, but in the meantime you can contact Quim Gil.--Qgil (talk) 17:44, 27 November 2012 (UTC)

The definitive landing place for new contributors
Getting involved in the MediaWiki community is not simple, and the problem starts with the unclear landing places. There is mediawiki.org homepage, Developer hub, Wikimedia developer hub, How to become a MediaWiki hacker and probably more. All in all they focus a lot on MediaWiki core and extensions development, when there is a lot more programmers can do these days, and plenty more than other types of contributors (testers, sysadmins, writers, promoters...) can help on. The project would focus on an engaging landing page, updating and improving current relevant pages and creating new pages if needed. We are looking for the right mentor, but in the meantime you can contact Quim Gil.--Qgil (talk) 18:09, 27 November 2012 (UTC)

Selection
These are the steps we are following for selecting our candidates:


 * 2012-12-03 - Deadline for receiving applications. Candidates still can finish their microtasks, polish their proposals and user pages. They can also reach out to the community and colleagues to get endorsements and support.
 * 2012-12-07 - First mentors meeting (private). Agreement on best candidates. Agreement on open questions and further actions in case o multiple candidates for one internship position.
 * 2012-12-10 - Second mentors meeting (private), if needed. Agreement on selected candidates.
 * 2012-12-11 - All accepted participants will be announced by the OPW admins.

Criteria
Mentors and community members are encouraged to help candidates improving their proposals based on these criteria. They help us evaluating a candidate and a proposal as a whole. We are not trying to build any scorecard to be measured with a calculator.

ESSENTIAL
 * Is your project proposal publicly available in a wiki page, containing answers for these questions?
 * Can you commit to the amount of time estimated by the program?
 * Are there two mentors (or at least one) committed to support you through the program?
 * Are the related project maintainers aware of your proposal, and are they willing to integrate the deliverables?
 * What skills and experience do you have to complete the project? URLs welcome.

RELEVANT
 * Why are you interested in joining this program?
 * Is your plan realistic, leaving time for tasks like community feedback, testing, documentation...?
 * Is there an emergency plan to be applied if the project is not completed by the end of the program?

VERY GOOD TO KNOW
 * Who else wants to help and see this proposal succeed? Do you have a section in your Talk page with endorsements?
 * Have you contributed to Wikimedia projects in any way before?

Process
The selection process starts right after the deadline for submissions. Most of the time is dedicated to gather community feedback about the proposals and polish the last details.


 * Each candidate must create a support section in their Talk user page: "Outreach Program for Women endorsements".
 * Community members and colleagues are encouraged to leave endorsements and feedback in that section. Don't forget to sign your comments!
 * Mentors might request additional information after the submission deadline.

Candidates are selected by consensus taking the selection criteria as main reference.

Mentors
Signed-up mentors
 * 1) Andre Klapper for bug report triaging
 * 2) MarkTraceur (talk) (via personal communication)
 * 3) Dereckson
 * 4) Jdforrester (WMF) (talk)
 * 5) Amir E. Aharoni (talk)
 * 6) Sharihareswara (WMF) (talk) 19:05, 13 November 2012 (UTC) I have too many candidates already and cannot respond to any more. Sorry. Sharihareswara (WMF) (talk) 14:31, 25 November 2012 (UTC)
 * 7) Jorm (WMF) (talk) 20:01, 20 November 2012 (UTC)
 * 8) heather walls (talk) 23:18, 21 November 2012 (UTC)
 * 9) MAssaf (WMF) (talk) 19:12, 26 November 2012 (UTC)
 * 10) Pginer (talk) 22:07, 27 November 2012 (UTC)

Org admin
 * 1) Quim Gil

Motivation
This initiative is suitable for the Wikimedia community because:


 * We'll make strong connections with a few talented people who will stick around
 * We can encourage people to work on testing, design, documentation, marketing, and other areas as well as code
 * It's a proven method for increasing the number and proportion of women in an open source community
 * Interns don't need to be students, so we're more accepting of age diversity
 * Instead of making newbies write fixed proposals with schedules, internships can follow broader charters and flex to accommodate students' interests and abilities