WikiReleaseTeam/Interviews with end users

This past month, the most effective action we took was to attend Wikimania. While there, I had the chance to talk with several people who run both large and small third-party wikis using MediaWiki. I asked them to describe the problems they saw with MediaWiki — places they thought improvement was needed.

The most consistant theme was the problem upgrading and using the new features that were being developed by the Foundation.

This was best summed up by Dror, who Amir Ahroni introduced me to when I asked for his input, he wrote:

… major features of MediaWiki, such as MobileFrontend or VisualEditor, are considered to be “merely” extensions. As such, they don't have real releases coordinated with MediaWiki releases, meaning I can't use them without keeping up with Wikimedia's branch - an impossibility with the 2-week deployment cycle, and even more so with the 1-week cycle.

This repeated over and over. To para

• Notes from talking to Quim
  • Clean install
    • Community portal?
      • Why?
    • Redlinks?
      • When you edit — “(see Espiral:Copyrights for details)”
      • licenses you upload
    • Current event
      • why?
    • help?
      • install default help
    • skinning
      • Flexible/fixed
      • Centered/left?
      • Font?
    • legacy skins
    • short urls
      • wiki knows, it should default
    • plug in data from wikiapiary for extensions
    • more feedback for extensions users
• Siebrand
  • 2 day notice on point releases
  • Clearer backporting policy
  • deprecations
    • deprecation extension

      “Brings clarity”

    • how to do this for core classes?
  • Changes in interfaces
    • removing parameters is bad
    • adding is ok
  • Jobqueue changes?
  • content type should assume text
  • What are going to do about global changes that are coming?
  • Skin/display separate better from “business logic”
  • Core devs in contact with extension devs
  • MediaWiki conference

Best practices

• • SMW and academics
  • ibm on authorship
  • Wikia contact — Mike Schwartz
    • skining
    • theme designer
• Amir
• dzahn
  • Popularity contest in installer
  • confirmedit
  • mailing
  • exploitable
  • spam
• jeroen
  • upgrading
  • extension
  • installing extensions like wordpress
  • how will this happen? conflicts
  • avoiding compatiblity breakage
  • ext devs should avoid depending on MW in ways they don't need to.
  • composer++
  • cultural problems
  • Too much dependence on WMF
• Ryan Lane
  • “Extension management is fucking huge!”
  • Configuration management is an issue, too
  • avoid making them depend on each other — it makes a big ugly mess
  • use the DB, dump it in memcache/apc — let wmf worry about cdb, etc
  • documentation of *how* to activate certain things or use particular configuration.
• Lee Worden
  • Jonathan Dushoff — partner in Canada
  • workingwiki
  • wiki farms made easy
  • upgrading
    • shared table upgrading test
    • Get notes from lee
  • supporting 1.19 + 1.21 is a pain
    • special upload modification
  • wonder or worden-lee (gerrit)
  • Multi-Upload for gerrit in 1.19+
  • register_globals
  • resource loader
  • don't put all the code in the webroot
    • api and index are all that are needed
    • don't make extension devs put their code in webroot (everything is fine except rl in debug mode)
• Manuel Schnider manuel.schneider@wikimedia.ch
  • running a wikifarm
  • fixing remove unused accounts scripts
  • get user scripts
• Axel Chowanietz axel@chowanietz.de
  • upgrading
  • has adapted his own RPMs
  • 50 wikis, largest with 50,000
  • patched addwiki.php
• Dror

Sorry for replying so late. I had a lot on my plate, but should have taken the time to at least say "later".

Anyway, I don't really have a prepared manifesto on the subject; I guess my biggest gripe would be the way that what I would consider major features of MediaWiki, such as MobileFrontend or VisualEditor, are considered to be "merely" extensions. As such, they don't have real releases coordinated with MediaWiki releases, meaning I can't use them without keeping up with Wikimedia's branch - an impossibility with the 2-week deployment cycle, and even more so with the 1-week cycle.

Another problem would be the documentation of infrastructure - everything is puppetized, which is nice, if you actually use puppet - but I'm just a single developer, poor ol' me. I can't afford to dig through piles of data to find out if I better use memcached or redis, and what resources does it require to run for a single server (not a huge cluster...), etc.

I know this might not be coherent enough - if you've got any questions to get me focused and make a point, I'd appreciate it :-)