Jump to content

Development tasks

Add links
From Meta, a Wikimedia project coordination wiki
(Redirected from Development task)

This page lists MediaWiki development tasks that are considered by its maintainers in consensus to be useful and important. The Wikimedia Research Network and other interested parties can use it to identify tasks for targeted development, and as a starting point to write specifications for individual tasks.

See /Archive for an old version of this page.

Suggestions

[edit]

Make it easier for a casual Wikipedian to find some place to report a Wikipedia problem or make a suggestion, and, deal with this serious issue --

Problem: All of the 1911 articles suffer from gruesome OCR (optical character recognition) problems. All words with accents are corrupted, all non-Latin alphabet (mostly Greek) words are complete gibberish.

Temporary Solution: Automatically add this text as a graphical "Wiki-template" box at the top of all 1911 articles:

READER ADVISORY: This article was scanned from the 1911 Encyclopaedia Britannica and converted to text using a highly flawed OCR (optical character recognition) application. All non-Latin alphabet words (such as Greek) appear here as gibberish. Many English words and most foreign Latin-alphabet words with accents (such as French) are also corrupted.

Real Solution: Re-scan the 1911 encyclopedia and OCR it with advanced multi-script software.

Some unrelated issues while I'm here:

Implement the ability to do hierarchical structures for long articles and/or complex subjects with "subject overview" pages and nested subpages, linked by "breadcrumbs" navigation at the top of pages.

Completely re-structure and organize the entire non-content areas of Wikimedia. It is an absolute usability nightmare to find any editing instructions, make suggestions, etc. Model who the different users are, what each user-type needs, and give each of them a link to a page with all, and just, their needs. I'm an occasional Wikipedia editor. I need a page I can go to with really concise, coherent, locked/non-discussed editing information (policies, style book, coding), and a way to report problems and make suggestions I can't deal with myself. I'd be happy to glance at a section where other casual editors post questions to see if I have any helpful answers for them -- this should be a new type of non-editable "question"/"reponse"-posts bulletin board, collapsed initially to a list of question subject lines, expand the question subject to read the question, and see a list of collapsed response subject lines. (This is also a suggestion for article Talk sections). Then off to the side of my "casual editor portal page", give me a panel of links to other stuff -- with an explanation of what each section actually does (Wikimedia Commons Village Pump??? Am I going to discuss George Bush there, or 1911 problems on Wikipedia, or uploading images to Wikimedia?)

Thank you for herding all of these comments to their appropriate location(s)... somewhere.

Oh -- and another thing. "Blind Wiki". (OK -- you PC the name for me). Wikipedia articles processed to remove (and describe) images, formatting that can't be machine spoken, etc., and then tested by volunteers with text-to-speech software. Set up some official coordination with a blind institution...

Just to add a few things here (I suffer the same problems as parent, the place for mediawiki suggestion/discussion appears not to exist for ordinary WP'ians - apart from jumping through the hoops of joining mailing lists etc.).
It struck me while reading through the current WP main page redesign talk page that the software needs to seriously be changed in regard to the formatting of talk. A bulletin board style would be most ideal, but obviously would require a large amount of coding, so I can see why that might not happen. However a simple solution would be to colour code threading in talk, ie. original 'post' is black, reply using ":" is blue, second reply "::" is green etc. etc. A two colour scheme would even be enough, just something to make talk a bit easier to follow. I mean have a look at the main page drafting talk
http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Usability/Main_Page/Draft
This is a project that is trying to reach consensus! - I struggle to even follow who is saying what as it all merges into one homogeneous jumble. If talk was just some added 'chat' feature then it wouldn't matter - but for core components of WP it is the pumping heart, where discussion and consensus are required before anything can happen. If it is as merged and difficult to interpret as that then it just makes everything that much harder, and makes everything take twice as long.
As with parent - feel free to move this to a more sensible place (if such a place exists, I browsed for 10 minutes looking, but didn't find a basic mediawiki suggestions page) SFC9394 23:27, 6 February 2006 (UTC)[reply]
"Voice Wiki" is more accurate than "Blind Wiki".Hillgentleman 05:52, 17 September 2006 (UTC)[reply]

Organization

[edit]

The tasks are sorted into three complexity levels: complex, normal, and easy. There is also a fourth category for bugfixes. Newbie developers are especially invited to pick tasks from the easy task list that have a potentially high impact.

For each task, the following fields are defined:

  • Bugzilla # - The numerical ID in our bug tracking system which identifies this task (should be a direct link). "N/A" if no entry exists yet, an entry should be created soon.
  • Specifications - A link to more or less detailed specifications for the task.
  • Short description - A short summary of the task.
  • Familiarity with MediaWiki - Extensions typically just require knowledge of PHP, while changes to the poorly documented parser are more difficult.
  • Familiarity with Wikimedia setup - If you want to write a script that converts all existing databases, a basic familiarity with the setup of the Wikimedia servers is important.
  • Participants - Anyone can list themselves as a participant for a project. However, only individuals marked with "*" are considered to be highly committed (relevant for next column).
  • Re-evaluate on - Only for tasks where there is already a highly committed user. If the task is not completed by this time, it should be re-evaluated in scope and participation. This is not a deadline, merely a point of reconsideration.

To do

[edit]

These tasks should be added properly to the table below. More can always be found in the list of Bugzilla entries by number of votes.

  • Wikinews
    • Basic scripting in templates (if/else logic is all that is needed)
    • Infobox auto-creator (working on this in PHP so even idiots can quickly create customized infoboxes)
    • 'Source' button on edit page to insert generic source
    • Search results need to have a "sort by date" option because date is more relevant in news than MediaWiki's "relevancy" calculations - which are rather irrelevant to our news.
    • Template:CURRENTDAY-1 function.
  • Use hashtable in memory for links lookup
  • Re-design page protection (c.f. MeatBall:FileReplacement)
  • Re-design page deletion (c.f. MeatBall:PageDeletion)
  • InstantCommons: use Commons content on any MediaWiki site (with local caching and size limits)
  • LiquidThreads
  • workflow features
  • Boolean queries on categories
  • Internationalization of categories
  • Synonyms for categories
  • Advanced blocking tools: soft blocking, anon-only blocking, per-page blocking
    1. Tim Starling installed "blocked user can edit his own userpage"
  • Anonymize IP addresses (hash?)
  • Better footnote and references support
  • Make intro section editable, improve section editing usability
  • Better subpage support (e.g. list subpages of a page)
  • Blog features like category RSS (currently exists as an orphaned extension), trackback, pings
  • Music playlists
  • Better content modularization for Wikibooks
  • Support for multiple content languages in one installation
  • New upload form (depends on Wikidata)
  • Fundraising code for Wikimedia
  • Web of trust features as alternative to sysop structure
  • External APIs (XML-RPC or SOAP)
  • Better redirect support (reasons shown instead/in addition to "Redirected from")
  • Structure category listings by namespace (450) and generally improve visualization
  • Translation interface
  • Icecast support for audio streams (extension)
  • improve spam blacklist and make it part of standard package
  • support for real-time editors like Gobby and MoonEdit (special page to check active sessions?)
  • support for real-time chat interface with built-in logging on talk pages
  • Make edit toolbar fully customizable
  • Add Special page that lists active users (users who have made edits within the past 15 minutes, customizable amount of time).

Complex tasks

[edit]

Create versioning system so people can see older versions of a page (within reason). Create system so users can easily vote on accuracy and informativeness of articles/Edits. If several reputable uses request that an edit be removed it can be done automatically without mods spending time. Track voter agreement as a way to determine voter reputation. This solves the problem of defacement. Since reputable voters can act as mods (within limits) this would also solve the problem of anonymous writing.

Bugzilla # Specifications Short description Familiarity
with MediaWiki 		Familiarity
with Wikimedia setup 		Participants

*=high commitment
$=subsidized development

Re-evaluate on
N/A Wikidata
Wikidata/Notes 		Structured data storage and retrieval high medium Eloquence*$ August 1, 2005

Importance: very high. Wikidata is key to the Ultimate Wiktionary and Wikispecies, and enables countless additional applications, such as a central data repository for Wikipedia which reduces the amount of duplication (similar to Wikimedia Commons), and structured data for image description pages.

N/A Semantic MediaWiki Easy editing of machine readable data, advanced semantic searching and browsing medium (extension) low/medium (minor database modifications) Markus Krötzsch* (for this table)
and many others*$ 		May 1, 2006

Importance: very high. Semantic MediaWiki allows you to add bits of machine-readable information in a user friendly way. With this data, one can greatly improve search and retrieval functions of MediaWiki at low cost, but also bring Wikipedias knowledge to desktop applications. Its effects resemble Wikidata, but it covers different usage scenarios. In its first stage (before Jan 2006), the project has implemented a first version of the extension, including support for typed links, datatypes, and the internal data storage. The next phase will provide data export and external reuse (searching, browsing, ...). Read on.

N/A piclab.com Create a standardized and consistent MediaWiki syntax high low (though it will require a conversion script) Lee Daniel Crocker* October 1, 2005

Importance: medium to high. Lee's proposal removes many quirks from MediaWiki's syntax and could contribute to a more consistent user experience. However, it is a major undertaking, as all existing wikitext would have to be converted. It is true that a switch will only get harder as more time passes.

57 Single login specifications
(see also: Single login) 		Single, persistent logins across all Wikimedia projects high high Brion VIBBER*$ September 1, 2005

Importance: very high. Many other tasks depend on this one, as it has the potential to greatly simplify all authentication processes. For example, when a file is uploaded or moved from a local wiki directly to the Wikimedia Commons, it is desirable to attribute this upload properly to the user who made it. Workarounds like "Eloquence@metawiki" notwithstanding, a global account database is the simplest way to do this. However, single login is a very complex project, as existing accounts from hundreds of wikis have to be migrated to the new system.

708 (tentative) A new look at the interwiki link (tentative) Redundancy-free interwiki and interlanguage link handling high low Eloquence
GerardM 		no firm commitment yet

Importance: high. The current interlanguage link system is highly redundant; if an article exists in 10 languages, the addition of an 11th language requires 11 pages to be edited. InterWiki bots can be seen as a workaround for this problem. A system of central link pools that a page can join may be more effective. Such a system could also encompass sister project links within Wikimedia, which are currently manually created using templates.

1394 (tentative) Commons usage tracking (tentative) "What links here" across projects (chiefly for Wikimedia Commons) high medium Eloquence no firm commitment yet

Importance: high. The Wikimedia Commons already hosts more than 100,000 files. Knowing where these files are used is essential to systematically add them where they are missing, and to clean up before deleting a file. It is also an important incentive to participate: seeing that a file is used can be very motivating. The implementation could be push- or pull-based. (Note that there is currently an external pull-based solution by Tim Bartel; the newly implemented one would have to be orders of magnitude more efficient.)

Done

[edit]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Development_tasks&oldid=24892748"