MediaWiki Stakeholders' Group/TechConf Input/Challenges

Gerrit
The Gerrit system for submitting patches is clunky, hard to work with, and generally unfavored in my office place. I was really hoping that with the moving to Phabricator another repository management system would have been implemented.

Alexia E. Smith (talk) 22:36, 3 August 2018 (UTC)

Endorsements

 * Alexia E. Smith (talk) 22:36, 3 August 2018 (UTC)

Comments

 * I would also prefer a move to GitHub --Krabina (talk) 11:51, 6 August 2018 (UTC)

Access restrictions and wiki synchronization
I know that MediaWiki is not designed to be a full-fledged content management system with fine-graind per-page or partial page access restrictions and probably never will be. But anyway, there two extensions that came quite far:
 * Extension:Lockdown
 * Extension:PermissionACL

So a first wish is one of them / or both to be maintained better or another solution to this.

In corporate settings, there are also alternatives to access restrictions in one wiki, i.e. splitting content in two or more wikis. Therefore a better multi-wiki-management and content syndication between wikis could be a way to go. Here are some links to follow up on that:
 * Extension:SplitPrivateWiki
 * https://github.com/nischayn22/wikiImporter
 * extension:Sync
 * Extension:Push

Also, a very simple use case cannot easily be implemented: setting up 2 wikis with a shared user accounts (but different content). So single-sign-on between two or more mediawiki instances is important in this regard as well (without having to use several extension).

Krabina (talk) 12:01, 6 August 2018 (UTC)

Endorsements

 * Krabina (talk) 12:01, 6 August 2018 (UTC)
 * AdSvS (talk) 12:58, 6 August 2018 (UTC)

Documentation needs a lot of improvement
I don't think I'm saying anything controversial here, but the documentation on mediawiki.org is often incomplete, outdated and sometimes misleading. I'll give one recent example: I was looking for how to view the current status of the job queue, other than just going into the database and looking at the "job" table. I went to the page Manual:Job queue, and the information there about viewing the job queue is in the section called "Special:Statistics" - which is odd because, as the text there notes, job queue information hasn't been available at Special:Statistics since 2010. The section then describes the API action to get the current number of jobs - which is helpful. However, there's also a script to see more information on the job queue, showJobs.php, and that one is only listed in the "See also" section. (And isn't there a way to call it from the web interface? I thought there was, but I don't see it now.)

Looking at the "Manual:Job queue" page, it looks like a lot of it could be overhauled. Why is a description of the asynchronous jobs setting contained in the "History" section? Why is there a "History" section at all? The average user has no interest in hearing about, for instance, job-related bugs that were fixed in 2014. This seems like it would be better kept in a subpage.

I think it would be great to have people whose full-time or part-time job is to maintain the documentation, and make sure that there's a consistent structure to it.

Yaron Koren (talk) 18:32, 6 August 2018 (UTC)

Endorsements

 * Yaron Koren (talk) 18:32, 6 August 2018 (UTC)

Keeping up with the upgrade debug cycle.
Every new release requires re-installation of extensions and checking that everything still works as expected. Most third party wikis stay at the original install version. Wiki users want to add content and keeping up with the upgrade debug cycle is a chore.

Rob Kam (talk) 08:28, 8 August 2018 (UTC)