Outreach programs/Possible projects

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 unless you've already talked to him about a microtask, 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)

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

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)