Third-party MediaWiki users discussion/Summary

This page holds a summary of third-party needs and wishes based on discussions held in January-March 2013 by User:Mitevam as part of her internship with WMF. The summary is based on public discussion on mediawiki.org and conversations on mailing lists and private email.

Better visibility

Third-party users, especially developers and hosting services, feel that their services should have more visibility on mediawiki.org. Visibility will help their business(if for-profit), but also help them get to know each other, learn from each other and collaborate and get more involved with the community. Visible success stories can also attract more people and organizations to use MediaWiki. So far WMF has been very conservative to post any third-party information directly on mediawiki.org and prefered directing such requests to external websites. However, now some information is up on mediawiki.org( specifically stating that WMF does not embrace the listed individuals and organizations).

What could be done?

• Have a clear policy on how much is OK to display on mediawiki.org and what is considered advertising or spam
• Keep MediaWiki testimonials up-to-date to show success stories
• Keep Software bundles, Hosting services and Professional development and consulting up-to-date
• Have regular presentations on various uses of MediaWiki and improvements by third-party users

Up-to-date documentation

MediaWiki documentation is often outdated, links to old systems like SVN are not replaced, examples refer to old versions, etc. Often multiple pages exist on the same topic, sometimes conflicting each other. It’s very difficult for a newbie to find out where to start from and to tell apart the useful information from the leftover out-of-date documentation. Part of the reason this is the case might be the fact that users who know how things are done don’t need to go back to the docs so they don’t see the inconsistencies to fix them.

One specific area, which needs improved documentation according to some third-party users, is the so-called PHP-API- the PHP classes and methods from core available to extension developers. Each class needs to be well documented in a way that allows a new user to start developing extensions without having to dig in the code. Deprecated methods should be announced in advance and supported for a few versions. Alternatives should be clearly stated. Also, a @since tag would be useful for developers working on backwards compatible extensions.

What could be done?

WMF could hold something similar to Bug Days, called Doc Days, where documentation on a given topic is reviewed and corrected. The areas where documentation needs more work can be ideintified through community feedback. Focus should be on lowering the barrier to entry for newbies.

Management of extensions

Extensions management comes in two parts:

Management of extension pages on mediawiki.org

This means having an extensions platform on the website, where extensions can be rated and commented on, searched through, etc. Each extension page should include specific information about the versions of MediaWiki the extension is compatible with, clear installation instructions and examples. Also, extensions can be rated on a variety of criteria like security, quality of code, usefulness, ease of use, etc. Extensions developers should be allowed to put a donation link on their extension page to fund the maintenance of the extensions. Users should be able to browse extensions according to rating, category, MW version. Also, good extensions should be recognized through a “featured extensions” process similar to “featured article”. Automation of compatibility testing would be best.

What could be done?

Some suggest using Semantic MediaWiki to manage extension pages and adapted Extension:ArticleFeedback for extensions rating. WikiVote are willing to offer one of their voting extensions for rating as well.

Extension management on MediaWiki installations for admins

This means having a UI admin panel in an installation’s Special pages, for example, which keeps track of all the installed extensions, allows admins to turn them on and off, notifies admins of available upgrades and lets them upgrade the extension from the UI.

What could be done?

Hallo Welt! has started developing an early version of this in BlueSpice and is willing to work further on it. Mark Hershberger(User:Hexmode]] has expressed interest to help make it happen. However, the completion of the Configuration Database is a necessary prerequisite and will hold back the project for another few months.

Upgrade platform

One of the major issues with MediaWiki is upgrading to a new version of the software. Many installations keep using versions as old as 1.12 due to compatibility issues. However, there installations are vulnerable due to lack of important security patches and cannot benefit from new features. An upgrade platform could help get more installations to use a supported version. The platform can be in the form of an UI accessed by sysadmins, which notifies them of available patches(including info about what was fixed), offers one click upgrade to the new version and clearly displays extensions compatibility, giving admins the option to disable incompatible extensions. Or if they want to wait, the platform could notify them once all extensions used on the installation are available in compatible versions.

What could be done?

In the short term, not much as it depends on extension management.

Fine-grained access control

Many third-party users, especially corporate, would benefit for more fine-grained access control, where information can only be available to certain authorized departments and sensitive personal data can be securely protected. However, access control is out of scope for the mainstream development of MediaWiki, given the openness and transparency of Wikimedia projects. Due to the nature of MediaWiki code, the existing tools suffer from severe security issues, especially for partly-private wikis.

What could be done?

MediaWiki is not designed to support fined-grained access. However, WMF could still help with the problem by:

• keeping documentation on access control up-to-date,
• documenting security issues and existing workarounds,
• whenever possible, prefer code which supports access control.

Wikimedia itself, and the WMF in particular, has dozens of private wikis as well and may potentially benefit from such features.

Integration with external tools

MediaWiki does not offer easy straightforward integration with external tools like social platforms, SharePoint, Excel, Google AdSense, Sitemaps, etc. Even though some (mostly partial) solutions do exist, integration, be it in core or extensions, should be improved and better documented. Different users have different needs in terms of integration. Corporate wikis, for example, want SharePoint integration or the ability to dynamically embed Word or Excel docs in the wiki. Any public wiki installation(including Wikipedia itself) would benefit from social platform integration.

What could be done?

Integration with certain tools could be a good project for interns.

Skins

There is only a few built-in skins that come with MediaWiki and most wiki’s look the same. It would be great to have more skins readily available or at least make it easier to make your own skin. Skinning needs to be better documented and better isolated from the rest of the code.

What could be done?

• Improve skinning tutorials and documentation to make it easier for developers to create skins.
• Isolate design from the code, so skin developers have more freedom and maintenance is easier.

Easier contribution

Code reviews are often slow and discourage third-party users to contribute patches. There is a general feeling that patches, which don’t directly affect the stability of WMF projects, tend to take longer to review.

What could be done?

• More developers with +2 status (especially volunteers) will help alleviate the problem and WMF is already working on that.
• Developers should be constantly educated about Gerrit/Code_review/Getting_reviews and Developers/Maintainers.

Transparency

I don’t have any specific examples to back up the claim, but I have heard a couple of times someone complain about important decisions about MediaWiki being taken in private. This is probably true to a certain extent and it is important for WMF to keep developers and third-party users involved in discussions and decisions by providing information, asking for feedback, etc.

What could be done?

Keep decisions open to the community, ask for and listen to feedback, discuss. If possible, hold work meetings online and post the logs and avoid private in-person discussions.

Semantic MediaWiki on mediawiki.org

A few third-party users have expressed interest in having SMW installed on mediawiki.org to help organize the information. One area SMW could help with is the management of extension pages (as mentioned above) but it could help with any other structured data as well.

What could be done?

The idea of installing SMW on Wikimedia websites has been suggested before but rejected by the devs as a wontfix. However, it has not been discussed about mediawiki.org. The first step would be to ask for the opinion of the broad community.