Parser 2011

Core projects
Wikimedia Engineering's key future-facing priority for 2011–2012 is creating a rich text editing environment, backed by a revamped, normalized, more consistent wikitext parser. Our 2011-2012 annual plan aims to "Develop Visual Editor. First opt-in user-facing production usage by December 2011, and first small wiki default deployment by June 2012."

Berlin initial notes

 * Berlin_Hackathon_2011/Notes/Saturday/Parser
 * Future/Parser plan
 * Future/Parser test cases
 * Future/Parser development: About the ongoing implementation effort
 * Future/AST (Abstract Syntax Trees)

Get involved

 * Join the wikitext-l mailing list if interested in following along or getting involved; there should be posts from Brion, Trevor, or Neil at least a couple times a week, and we're going to need feedback and help!
 * Give feedback on the initial prelim docs & demos via Future/AST (to come soon)
 * Collect references to existing alternate parser output formats via Future/AST
 * Collect test cases (example pages, known problematic pages, corpus from Wikipedia, adapted parser tests) via Future/Parser test cases

Project notes
Preliminary notes pages, which will be replaced shortly by the above project pages as they are fleshed out.

Potential projects
''For now this is an initial page listing some of my personal priorities for the MediaWiki Labs/future workgroup. Individual projects will be solidifying into the roadmap and requests for comment pages as well. --brion 21:28, 11 April 2011 (UTC)''

Some of these projects are high on Brion's personal list, but haven't yet had official resources assigned to them. Hopefully we'll get some of them started in 2011 while the parser projects are still in play.

Background
MediaWiki as we know it had its basic architecture set in 2001-2002, based on the then-needs of Wikipedia migrating off of UseModWiki. This has locked in a number of assumptions which have been difficult to break out of.

What's changed?

We've also seen some interesting changes within our own community which can point us at some interesting directions:
 * Custom user and site JavaScript and styles and l10n messages have made a lot of customization and some local features possible that would never have gotten done by core developers. With the in-browser JavaScript+HTML+CSS environment only getting awesomer as browsers evolve, this is a key environment for feature expansion and creative content creation. Make it easier to create and share things; find ways to remove bottlenecks to sharing code between users and between sites, and making it safer to do so by devising restricted execution environments.

Values
Major future-oriented projects should consider the core values of a wiki environment. What are some key properties of wiki, and what are current holes in that that we can fill in by modernizing?