During this year’s Wikimania, we had several meetings that will affect the work of the release team. One of the most important was the Developer Discussion that I initiated after Daniel Schneider commented that “It might be a good idea to address those issues in some next important dev meeting. The meeting should be chaired by someone from the outside, e.g. from a well respected foundation like Mozilla, Apache.” We had the meeting and Markus Krötzsch, creator of Semantic MediaWiki, agreed to moderate the meeting.
You can read the rough transcript that Markus Glaser kept for us to find out more details about what was discussed, but I’ll synthesize what I think are the important action items and take-aways for the MediaWiki release team.
These fall into three groups: the installation and upgrade process, code deprecation, and, finally, one that overlaps with all of these, a system of certifying extensions.
The effort to provide some standard for extension certification will bear the most fruit because it means providing a standard for MediaWiki that creates a virtuous circle that will lead to improvements in the MediaWiki ecosystem.
It seems obvious to me that we need to start from where we are: a lot of users are using extensions like Semantic MediaWiki and consider those extensions (as Natasha Brown, who runs WikiTranslate.org pointed out) to be an integral part of their site.
This means that we can begin by making a base for certification that covers some things that decently-maintained extensions should have no problem following. This would include things like internationalization and localisation support, including unit tests, and sane integration with the upgrader and installer.
Ideally, none of this would need to be manually tested. This means that to get a rating, your extension would need to be automatically tested. Composer seems like it would help out a lot here. It already provides a framework for fetching code from git – and we should only need to let developers provide a <tt>composer.json</tt> and then we would have a bot (running from Wikimedia Labs) test the package and then provide a certification.
Through this automated certification, we could begin to provide guideance on the “best practices” method of upgrading or handling configuration (probably using Kunal’s configuration work).
The discussion also raised the visibility of Bartosz Dziewoński’s Google Summer of Code work which provides some sanity to MediaWiki’s skinning system. This is a major pain point for many wikis stuck on older versions of MediaWiki – they’ve done a lot of work and customization on appearance and avoid upgrading because the disadvantages of the tight-coupling that MediaWiki’s skinning system has shown until now.