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)

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)

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)

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)

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)

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)

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)

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)