Outreach programs/Possible projects

MediaWiki API / Wikimedia data
MediaWiki API has matured enough to need a significant Botox injection. Some of the API directions to improve include
 * Localized errors and warnings
 * RESTful style Content API
 * API versioning
 * Cleanup module and parameter naming in 2.0, refactor module features
 * Interactive auto-generated API help system
 * Reference implementation of the API client library (python? javascript?)
 * And many more items from the roadmap list

Wikidata's wikibase modules can also use many API improvements to make them part of the query system.
 * list=wbsearch
 * prop=wikibase


 * Willing to mentor. --Yurik (talk) 13:10, 22 March 2013 (UTC)

XML dumps
The dumps for the larger projects are only getting larger. A downloader of the English language Wikipedia dumps needs to download 40GB or so of data each time the dumps are produced, when 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, that did not rely on uncompressing the previous month's dumps, scanning through all revisions (10T worth), and then repackaging them all. Imagine running the German language Wikipedia dumps in 3 days instead of 16, with a single process running.

This could be achieved by designing the right output format for the XML files containing text for all revisions. It would need: a smart choice for compression of multiple items together, an index into the compressed blocks, a way to remove content quickly, possibly leaving zeroed blocks bhind, a way to re-use empty blocks. To use the new archive format, we would need tools to convert to bz2 or 7z (so users can keep all their existing scripts for the dumps), a format for storing isolated sets of changes (so dump users can download just these sets), a script to apply those changes to the above format (so users can run the script against the change set and their full dump to update their copy). It would likely need to take as input an XML file of new pages and new revisions for old pages, as well as a list of pages and/or revisions that have been deleted in the meantime; this would entail no changes to MediaWiki core, all of the work would be done by a separate set of tools.

I am willing to mentor such a project. -- ArielGlenn (talk) 10:51, 25 March 2013 (UTC)

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.

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)

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.

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.

Improve Extension:CSS
The CSS extension relies on basic blacklisting functionality in MediaWiki core to prevent XSS. It would be great if a proper CSS parser was integrated and a set of whitelists implemented to offer various levels of capability/protection trade-offs.

For example, some wikis may want all CSS selectors prefixed with "#mw-content-text" and properties like "position", etc. disabled to limit the effect of styles to the article content. Other sites may want everything except XSS-able properties/values.

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.

Necessary Skills/Interests: PHP, CSS, JavaScript, web application security

Mentor: Rusty Burchfield is willing to mentor an intern on this project.

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

co-ment-like tool for inline comments
An inline comments extension, similar to stet or co-ment but integrated into MediaWiki. It would help people make useful comments about specific parts of articles, as part of collaborative work.

Mentor: Matt Flaschen

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.

Automatic category redirects
Short version: Solve 3311

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 and should certainly be do-able in the length of a gsoc/mentorship program.

This project would also be quite beneficial to several wiki projects, especially multilingual projects like Wikimedia Commons.

(Project idea suggested by user:Bawolff)

Wikidata
Wikidata is a new Wikimedia project to build a free and open knowledge base that can be read and edited by anyone. You can help make the project even more useful and great by contributing one of the projects below. If you want to start coding then these tasks are a great start. in case of questions you can contact Lydia Pintscher.

Entity Suggester
Wikidata could be a lot smarter than it is right now. This is your chance to make it quite a bit smarter. When an editor edits an item about a person for example 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.

Contact: Lydia Pintscher

3rd party client
Currently Wikidata is only set up to directly serve data to the Wikipedias. The goal of this project is to also allow 3rd party clients to consume Wikidata data in the same way. See Extension:Wikibase Client.

Contact: Lydia Pintscher

Mobile website
The goal of this project is to create a mobile version of the Wikidata website for easy reading and editing on phones.

Contact: Lydia Pintscher

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!