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

Intro tasks
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)

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.

Communications
Sumana Harihareswara is the mentor for each of these topics.

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.

You need to be able to write English prose.

Operations overview
Check out Manual:MediaWiki architecture. We wrote that last year to give developers an overview of how the MediaWiki application works. But how are the servers set up, and what's the history and future of Wikimedia operations? We'd love for you to write an overview of our Operations (systems administration) infrastructure.

You need to be able to write English prose.

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.

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.

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)

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)

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