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)
 * Corey Chambers (talk) 00:11, 11 August 2018 (UTC)
 * James Martindale (talk) 19:04, 13 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:22, 14 August 2018 (UTC)
 * Kaldari (talk) 21:47, 14 August 2018 (UTC)

Comments

 * I would also prefer a move to GitHub --Krabina (talk) 11:51, 6 August 2018 (UTC)
 * Gerrit is unnecessarily difficult for new users to get used to. Moving to a service such as GitHub would allow new users to more easily contribute to existing projects by taking advantage of things like browser editing. Corey Chambers (talk) 00:11, 11 August 2018 (UTC)
 * I find GitHub's code review interface far easier to work with than Gerrit's. James Martindale (talk) 19:04, 13 August 2018 (UTC)
 * Anything would be better than Gerrit. GitHub is obviously the best option as far as UI and existing community, although politically it's problematic due to its commercial nature. Kaldari (talk) 21:47, 14 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)
 * --&#91;&#91;kgh&#93;&#93; (talk) 11:20, 11 August 2018 (UTC)
 * (ACL is a missing core feature that does not contradict the Wiki idea, because you can - and should - deploy flat authorization hierarchies. But the lack of this configuration option complicates often development projects and the introduction of MediaWiki in organizations outside of Wikimedia.) RichardHeigl (talk) 12:09, 11 August 2018 (UTC)
 * (This challenge is related to my own below) Even Thorbergsen (talk) 20:28, 12 August 2018 (UTC)
 * --MGChecker (talk) 22:16, 13 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:23, 14 August 2018 (UTC)
 *  ·addshore·  talk to me! 09:49, 14 August 2018 (UTC)
 * Remco de Boer 15:23, 14 August 2018 (UTC)

Comments

 * This would be useful for hiding rough drafts of articles while they're being worked on, until they're ready enough. Rob Kam (talk) 10:07, 8 August 2018 (UTC)
 * for this you should look into Extension:Approved_Revs --Krabina (talk) 09:23, 10 August 2018 (UTC)


 * Indeed the "Lockdown" extension is more or less causing issues since MW 1.27 due to a bug apparently in core. --&#91;&#91;kgh&#93;&#93; (talk) 11:21, 11 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)
 * Bryandamon (talk) 18:14, 8 August 2018 (UTC)
 * Corey Chambers (talk) 00:12, 11 August 2018 (UTC)
 * --&#91;&#91;kgh&#93;&#93; (talk) 11:23, 11 August 2018 (UTC)
 * --MGChecker (talk) 22:16, 13 August 2018 (UTC)
 * — AfroThundr (u · t · c) 00:30, 14 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:35, 14 August 2018 (UTC)
 *  ·addshore·  talk to me! 09:49, 14 August 2018 (UTC)
 * Alangi Derick (talk) 13:03, 14 August 2018 (UTC)
 * Remco de Boer 15:24, 14 August 2018 (UTC)
 * Kaldari (talk) 21:48, 14 August 2018 (UTC)

Comments
This is a very key area in MediaWiki development and I must appreciate that of course there is a lot of documentation already which exist but since software changes are inevitable, it should be noted that as these changes are done periodically, their docs counterparts should be improved in order to keep everything up to date. It's a key way of technical contribution in the movement and while trying to do this, one will find his/herself navigating MW code and software etc. There are many advantages of improving MW related documentation especially to developers and newbies so it should be treated with priority. :) --Alangi Derick (talk) 13:07, 14 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 too technical a chore.

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

Endorsements

 * Liuxinyu970226 (talk) 01:35, 14 August 2018 (UTC)
 * Alangi Derick (talk) 13:07, 14 August 2018 (UTC)

Most people are not drawn to use wikis
Wikis needs collaboration to function well. The biggest challenge is lack of other wiki contributors with know-how to share. Most frequently when people announce (on email lists or forums) some information they’re organising and making available; even if they know of a wiki for that subject they do it their own way, e.g. posting on a forum, blogging, YouTube, file-sharing, Google docs, GitHub repository, etc. but rarely a new wiki article on an existing specialist wiki. While on the other hand some competent authors are repelled by the idea of writing on a topic and then having to allow anyone to make changes to their work.

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

Endorsements

 * Liuxinyu970226 (talk) 01:35, 14 August 2018 (UTC)

Guarding against link rot
The MW extension ExternalLinks is unsafe because of the risk of XSS. It was an easy and efficient way to easily maintain a wiki's external links. Wikis could/should have Special:External links where any broken external links get flagged up.

Rob Kam (talk) 09:47, 8 August 2018 (UTC)

Endorsements

 * Liuxinyu970226 (talk) 01:36, 14 August 2018 (UTC)

Enabling public read access to specific pages of a private wiki
It should be easy to make specific pages of a private wiki publically available, while all other pages stay private. Setting a category display property is a possibility. This is related to Access restrictions and wiki synchronization above, and may possibly be solved by Extension:SplitPrivateWiki.

Even Thorbergsen (talk) 14:44, 12 August 2018 (UTC)

Endorsements

 * Even Thorbergsen (talk) 14:44, 12 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:37, 14 August 2018 (UTC)

Comments
In a private wiki not behind a firewall, you can add pages you want the public to see with $wgWhitelistRead on LocalSettings.php. To easily do this, you can load the InternalWhitelist extension which provides a Wiki page (MediaWiki:Whitelist) to which you can add all pages you want publicly available. Making the MediaWiki:Whitelist page protected can limit who can make pages public. Bryandamon (talk) 06:01, 14 August 2018 (UTC)

Replicating templates and modules from Wikipedia to an Enterprise wiki
Could it be made easier to be able to copy over a template, its documentation, any of required templates, their documentation, those templates required template, their documentation, any requirement modules, and their documentation? I feel this could be done using Special:Export if you would specify the list of all of the templates and modules, but getting that list might be very time consuming and prone to errors. Thanks!

PhotographerTom (talk) 17:55, 13 August 2018 (UTC)

Endorsements

 * PhotographerTom (talk) 17:55, 13 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:37, 14 August 2018 (UTC)
 * Bryandamon (talk) 06:03, 14 August 2018 (UTC)
 *  ·addshore·  talk to me! 09:49, 14 August 2018 (UTC)