Outreach programs/Possible projects



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
Any potential contributor is encouraged to follow the Landing instructions. Use your user pages to introduce yourself and draft your project. 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.

Insider's tip: Think that people is usually busy or simply living in different timezones: let the Earth spin once before becoming impatient. Dealing with high traffic developer lists and IRC channels is not simple, but you will get plenty in return (here just like in any other open source project). Be patient, learn to filter what is not relevant to you and just let it flow.

Selected project ideas

 * We are working on them. Your feedback is welcome.

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 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, source code, poems, timelines…

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

Mentors: James Forrester.

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.

Entity Suggester
Wikidata, and specifically the Wikibase extension, could be a lot smarter than it is right now e.g. by suggesting fields to fill and probable values. For example: when an editor edits an item about a person that is still missing the date of birth, this should be suggested as a possible property. Or when the editor is entering the sex of the person, Wikidata should be smart and suggest the ones that are used most for these properties first. Think of it as something very similar to the famous "people who bought x also bought y" systems.

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.

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

Mobilize Wikidata
Wikimedia sites use the MobileFrontend extension to render automatically a mobile UI on mobile devices. We haven't enabled a mobile view for Wikidata yet. While MobileFrontend focuses on rendering articles, Wikidata pages are quite special: they are basically made out of grids of  elements and tables containing text values. We need to agree on solution and implement it. Bonus point: can you implement an effective way to edit data fields from a mobile device?

Skills: PHP, Javascript, HTML. Experience developing mobile UIs will save you a lot of unsuspected headaches.

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.

Incremental data dumps
We offer data dumps of Wikipedia and other Wikimedia projects, allowing people to access to this knowledge where Internet connection is impractical, very costly or non-existent. The dumps for the larger projects are only getting larger i.e. 40GB for English Wikipedia. What is more, the update a month later will be another 40GB or more. In fact, only a small subset of that information is actually changed in the form of new pages, new revisions, or deleted revisions. Imagine if users of these files could download just the changes, plus a script that applied the changes. Imagine if the dumps could be written out using the previous month's dumps with such a scheme. Imagine running the German language Wikipedia dumps in 3 days instead of the current 16. This could be achieved by designing the right output format for the XML files containing text for all revisions.

Skills: XML, a scripting language such as Python or Perl

Mentors: ArielGlenn.

Prototyping inline comments
Editor engagement is a top priority that we are addressing with several projects. You could help by prototyping one that we would like to see working in MediaWiki: inline comments. Imagine: a user lands in a Wikipedia article, selects one sentence and leaves an inline comment that others can optionally read and reply to. Check this historical example. It would help people make useful comments about specific parts of articles, as part of collaborative work. This feature could fit perfectly with the purpose of a wiki. Be the one trying out.

Skills: Javascript, PHP, MySQL. UI design skills are also useful although not required to build a technically solid prototype.

Mentor: Matt Flaschen.

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. 

= Raw projects =

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

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

Phase out the Vector extension; merge the good parts into core
Vector has outlived its usefulness as an experiment. The good parts should be merged into core MediaWiki; either into the Vector skin, or as core features. Check the details at the request in Bugzilla and related bug reports.

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

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: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

Add support for x3d 3D files to MediaWiki
A lot of users are requesting the ability to upload 3D files [in the x3d format to Wikimedia Commons. But for that creation of a sanitizer and integration of a rendering system is needed.

This project idea contributed by Tpt (talk) 16:38, 12 February 2013 (UTC)

Improve the mediawiki-bugzilla extension to a deployable level
Mozilla has developed a MediaWiki extension which allows for read-only inclusion of bugzilla content in MediaWiki pages by using Bugzilla's REST API. They use it for example to provide "Mentored Bugs" sections (example) but it could be used for a lot of things, like basic prioritization or todo list for specific products/components.

It looks like there are still a few major bugs with the extension, and more work is probably needed to make it deployable on Wikimedia wikis (or at least MediaWiki.org). I'm sure the Mozilla folks would be happy to help or co-mentor someone willing to improve the extension. Our community has enormous expertise about MediaWiki, and theirs has enormous expertise about Bugzilla, so this would be a perfect fit.

(Project idea contributed by guillom)

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

Improve Page: edition of Proofread Page
The Proofread Page extension is an old extension developed by the Wikisource community that manage the Wikisource Proofreading system. It needs some love in order to make it use new technologies of MediaWiki core and to integrate it into the Visual Editor. Here is a list of some tasks that should be done:
 * Refactoring of the extension code by splitting the very big file ProofreadPage.body.php that do too much things into specific classes what will be more easily testable. Write unit tests for them.
 * Refactoring of the JavaScript module that manages edition of Page: and make it compatible with the Visual Editor. This includes:
 * for wikitext editing system a full rewrite in order to make the code readable and testable. The tasks would be:
 * move to server part of the extension things that can be done by it as it have been done for Index: pages.
 * use libraries packaged with MediaWiki like JQuery when possible.
 * find and use a good free JS library for zooming into scans in order to improve the current zoom feature that might be enhanced.
 * work with the Visual Editor team in order to make the Visual Editor work with Page: pages (bugzilla). The first step is to make the body of the page editable, then the proofreading level and, if it's possible, header and footer.
 * Add modules to the Visual Editor to support specific tags used by Wikisource like, and.
 * Allows to edit using the Visual Editor textareas of the Index: pages form.

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

Improve accessibility of MediaWiki and MediaWiki extensions
W3C has a set of accessibility guidelines to make web content accessible to people with disabilities. The student will assess, update and resolve already identified accessibility issues in MediaWiki and MediaWiki extensions, as well as audit MediaWiki and selected MediaWiki extensions deployed by Wikimedia against the accessibility guidelines, and report and resolve found issues as much as possible.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Tools for migration to structured page translation
The MediaWiki Translate extensions has a feature called page translation. This allows structured translation of documentation, among others, tracking changes in the source page (usually in English), to make the life of translators easier. Often, wikis have a lot of legacy content, that would require manual conversion to the new system. Not many users are eagerly waiting to work on this. The student will investigate possibilities for developing tools to facilitate conversion from unstructured translation to the Translate extension page translation feature, to speed up the transition process, and develop and implement the most feasible solution for at least one Wikimedia wiki. This process has to happen in collaboration with at least two existing community members, to guarantee a sustainable and workable deliverable.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

ULS gadgets framework
No details yet.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

OCR for Wikisource
No details yet. See Extension:Proofread Page, available in Wikisource.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

Create plugins for jQuery.IME for Firefox and Chrome
jQuery.IME is a collection of open source input methods. The student will port the jQuery plugin to Firefox and Chrome extensions in a sustainable way, so that updates are made easy, and publish the extensions to repositories used by the browsers so that users can download, install and use jQuery.IME in every website they visit.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

Multilingual, usable and effective captchas
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.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

Language Coverage Matrix dashboard
No details yet.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

MediaWiki LocalisationUpdate for all
No details yet.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

Wiktionary APIs
Making Wiktionary more machine readable via APIs. See.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

Multilingual SemanticMediaWiki
Semantic MediaWiki is cool, but it would be even cooler if it was multilingual-capable out of the box. Integrate it with Translate extension. See.

Possible mentors: At least one member of the Wikimedia Language Engineering team

Disclaimer: This a long list proposal. The team will assess this long list on 2013-03-28 and update it with more specific information, or retract it.

On-site editing
Wikidata provides data for Wikipedia's infoboxes. The goal of this project is easy editing of the data for a given infobox on the Wikipedia, without having to go to Wikidata. See also and.

Contact: Lydia Pintscher

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

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)

Browser Test Automation
The goal would be to create decent test coverage for a feature or an extension. For more information about browser automation please see Groups/Proposals/Browser testing page.

Good example would be Extension:MobileFrontend extension. It already has a few tests in tests/acceptance folder and three Jenkins jobs: the same tests run on Android, iPhone and iPad. There is also a Mobile tests section at QA/Browser_testing/Test_backlog page.

Please note that MobileFrontend is just an example. Any other feature or extension could be the target.

This project idea contributed by Zeljko.filipin(WMF) (talk) 11:00, 30 January 2013 (UTC) (a mentor)

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)

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 http://svn.wikimedia.org/doc.

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.

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.

Success stories
Update Mediawiki Testimonials, interview users about their success stories and make them visibly on mediawiki.org to promote MediaWiki as a product and attract more users, volunteers, etc. Start a “Feature story” campaign with weekly(?) success stories and user cases presented at a visible location. Organize user presentations, where one individual developer/company can present how they use/adapt MediaWiki, to help the community to share and learn from each other.

Things you might need to know: English prose, planning and organization skills.

Sumana Harihareswara can mentor this project idea.

Extension pages management
Extensions on mw.org are not very well organized and finding the right extension is often difficult. The community needs better management of extension pages with categorization, ratings on code quality, security, usefulness, ease of use, etc. Good extensions should be given more visibility. “Featured extensions” similar to featured articles could be introduced.The compatibility of extensions with different MW versions should be clearly displayed and possibly compatibility testing should be automated. In terms of implementation, some suggest using SMW for the organization of the data and Article Feedback for rating. Developers should be able to add a PayPal account link to fund the maintenance of their extensions. Note: This project should probably be implemented by someone with a lot of experience with MediaWiki, maybe a core developer. An intern could work on pre-implementation work such as collection of requirements and detailed design/specification.

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!