The Platform Evolution Program team is gathering input from a variety of groups with an interest in MediaWiki. This input will be provided to the Program Committee for the Wikimedia Technical Conference to assist them in designing the program for the conference. The MediaWiki Stakeholders' Group is helping the Platform Evolution Program team by coordinating responses from people and organizations who are using MediaWiki for non-Wikimedia projects.

If you use or maintain a wiki powered by MediaWiki - a personal wiki, a wiki or wiki farm for an organization or company, a wiki for a community group, a wiki hosting service - that is not part of a Wikimedia project, please provide input below. It's OK if you also participate in Wikimedia projects, but please restrict your answers below to non-Wikimedia projects.

Your feedback will help and frame the Platform Evolution discussions, seeking to answer open questions, explore governance models, and identify key MediaWiki features for future development. The output from the Wikimedia Technical Conference will form the basis of the Platform Evolution Program which will directly drive the future development of MediaWiki.

Thank you!

Please answer the questions below. You may provide multiple answers to each question. For each question, use the input box to create a new section, outlining your response:

In the input box put a short headline for your response. Pressing the button will then take you to a form to enter your full response.
Try to keep your response general, rather than focusing on one specific implementation, where possible.
If there are any relevant wiki pages, Phabricator tickets, mailing list discussions, etc., please link them as well.

In addition to answering the questions, please endorse responses entered by others. This will help us prioritize the responses.

Underneath each response will be a section for endorsements (and any brief comments) and another for longer comments.
To endorse a response, please click the [edit source] beside the Endorsements header under the response you wish to endorse. Then, add a new line containing:
* (optional brief comment here) ~~~~
To comment on a response, please click the [edit source] beside the Comments header under the response on which you wish to comment. Then, add a comment.
Please check back often so you can endorse any new responses that are relevant to you.

Deadline: Please respond below no later than August 19, 2018.

Conference topics

What are the most important topics that should be discussed at the Wikimedia Technical Conference?

How can we create a governance model?

There is no clear decision making process for MediaWiki. I would love to see us start on a process whereby we could predict what was happening with the software in the next year. We have some vague ideas, but no unified driving force.

☠MarkAHershberger☢(talk)☣ 19:45, 3 August 2018 (UTC)[reply]

Endorsements

☠MarkAHershberger☢(talk)☣ 19:45, 3 August 2018 (UTC)[reply]
Alexia E. Smith (talk) 22:36, 3 August 2018 (UTC)[reply]
--Krabina (talk) 11:47, 6 August 2018 (UTC)[reply]
--[[kgh]] (talk) 11:06, 11 August 2018 (UTC)[reply]
RichardHeigl (talk) 11:56, 11 August 2018 (UTC)[reply]
「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:49, 14 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:19, 14 August 2018 (UTC)[reply]
Nischayn22 (talk) 08:31, 14 August 2018 (UTC)[reply]
·addshore· ^{talk to me!} 09:50, 14 August 2018 (UTC)[reply]
Remco de Boer 15:22, 14 August 2018 (UTC)[reply]
Jayprakash12345 (talk) 08:11, 17 August 2018 (UTC)[reply]
MarcvHoof (talk) 14:04, 17 August 2018 (UTC)[reply]
Mglaser (talk) 21:15, 17 August 2018 (UTC)[reply]
HakanIST (talk) 06:29, 18 August 2018 (UTC)[reply]
DuncanCrane (talk) 11:17, 18 August 2018 (UTC)[reply]
--Toniher (talk) 10:48, 18 August 2018 (UTC)[reply]
James Martindale (talk) 19:01, 19 August 2018 (UTC)[reply]
Rudolf.Grossmann (talk) 21:16, 7 September 2018 (UTC)[reply]
...

Comments

A text suggestion tool

It's helpful to have a text-editing tool that helps contributors write better sentences

Endorsements

Although I don't know who said this section, I support this. --Liuxinyu970226 (talk) 01:20, 14 August 2018 (UTC)[reply]

Comments

Activate Grammarly. Grammarly is the best grammar editing tool out there. Zzmonty (talk) 10:34, 14 August 2018 (UTC)[reply]

Lack of templates in MediaWiki

Templates are missing from Wikimedia. These are a headache to disentangle, understand, install and maintain for the end user who would rather be concentrating effort on adding wiki content. Individual wiki admins are forced to either write their own templates or export them from elsewhere e.g. Wikipedia.org. This is a wasteful dispersion of effort in place of collaboration. The templates that are exported from Wikipedia or Mediawiki are not universal and the target wiki then includes references to these sites instead of to itself.

Rob Kam (talk) 08:21, 8 August 2018 (UTC)[reply]

Endorsements

「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:49, 14 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:21, 14 August 2018 (UTC)[reply]
nBarto (talk) 15:31, 15 August 2018 (UTC)[reply]
Rob Kam (talk) 17:22, 15 August 2018 (UTC)[reply]
Awangba Mangang --Awangba Mangang (talk) 04:37, 16 August 2018 (UTC)[reply]
• speedy • 🔔︎ • 🚀︎ • 13:24, 16 August 2018 (UTC)[reply]
DuncanCrane (talk) 11:17, 18 August 2018 (UTC)[reply]

Comments

This could be provided by a wiki repository, similar to Wikia/Fandom's Starter Wiki. This repository would have to be licensed as CC0, and there are open questions about maintaining multiple versions of templates, mostly in regard to whether the target wiki has installed features such as Scribunto or TemplateStyles. Since not all templates are of interest to all wikis, some sort of template pack feature, above and beyond just listing things on Special:Export, would be desirable (if designed/implemented correctly, this would also simplify and streamline selecting the correct version of templates for a given installation). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 00:49, 14 August 2018 (UTC)[reply]

or just add it to http://commons.wikimedia.org -- make a new section called "Template-repository:" and "Module-repository:". Although the templates would need to be organized between general use templates and templates with information specific to a specific project. I like the infoboxes, but I do not need many of the other templates that get included when I say "export referenced templates". Also, the export would need a feature to rename "Template-repository:" to "template:", so the end user does not need to do that themselves. Zzmonty (talk) 10:38, 14 August 2018 (UTC)[reply]

To expand on the OP, a lot of Wikipedia/Mediawiki templates are dependent on Scribunto (which users struggle to debug after importing). The Module namespace at Wikipedia has quite a bit of overengineered code as well. Think mobile too - all extension infoboxes on mediawiki.org look awful there. • speedy • 🔔︎ • 🚀︎ • 13:24, 16 August 2018 (UTC)[reply]

I'm using a wiki farm to provide a 'software as a service' environment to my users. Ideally they should have identical functionality with their content stored in unique wiki databases for each user (or group of users). The functionality I create uses templates a lot - Page Forms, Cargo, SemanticMediaWiki - so it would be great to be able to share templates in a straightforward way. Currently I am duplicating the functionality in each wiki which makes it difficult to maintain. Perhaps it would be possible to set a configuration variable to always transclude templates from a particular wiki? Alternatively, it would be useful if, when transcluding a template from another wiki, all templates referenced were also transcluded from the same wiki. If this is already possible it would great to know how? The suggestions I've seen so far appear quite complex to implement. DuncanCrane (talk) 11:18, 18 August 2018 (UTC)[reply]

You'd also have to transclude any modules the templates use. Rob Kam (talk) 16:18, 18 August 2018 (UTC)[reply]

Somehow this topic was split into several variations of the same topic. I guess I endorsed one of them. --[[kgh]] (talk) 08:52, 19 August 2018 (UTC)[reply]

Also a solution to this issue is listed at Meta:Community Wishlist Survey 2019/Miscellaneous/Shared Multilingual Templates and Modules available to all wikis, please support it. Rob Kam (talk) 09:01, 18 November 2018 (UTC)[reply]

Release management unclear. Is there still one?

It appears that doing point releases when it comes to maintenance was apparently abandoned along the way. During the past nine months we have only seen two feature releases with unreleased fixes now piling up for both of them not to speak about the other older LTS branch and the regular branch still active sharing the same fate.

I suggest to reinstate doing point releases for maintenance purposes and to e.g. have a point release every quarter of a year - something somewhat predictable and plannable.

Endorsements

[[kgh]] (talk) 11:16, 11 August 2018 (UTC)[reply]
— AfroThundr ^{(u · t · c)} 00:26, 14 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:21, 14 August 2018 (UTC)[reply]
--Felipe (talk) 07:36, 15 August 2018 (UTC)[reply]
MarcvHoof (talk) 14:05, 17 August 2018 (UTC)[reply]
DuncanCrane (talk) 11:19, 18 August 2018 (UTC)[reply]
Mglaser (talk) 21:32, 19 August 2018 (UTC)[reply]

Comments

Figure out why scribunto has issues when trying to install from a 1.27 release to a 1.31 release on a shared host. Maybe I did something wrong, but if I can't get scribunto to work (requirement for using current templates and modules), I can't upgrade to 1.31.

Maybe the solution is to create two install versions. One is basic install with the bare bone minimums, and one is an enhanced version (the end user is planning to import templates, so they need all of the extensions that make the templates work properly). If that was provided, I would upgrade from 1.27 LTS to the 1.31 LTS. I am sure that I am not the only end user in this position.

Finally, have an auto LTS upgrade that will automatically upgrade the source code and extensions, similar to the way that WordPress does it. Maybe this can be restricted to just the extensions that are included in Wikipedia (and its sister project installs).

The easier the upgrade process (end user does not worry they are going to mess up their site and be down), the more likely the end user will upgrade and the less need their will be to maintain old releases. Thbis does not need to be done for every release. Just the long term releases, because those are the releases that less technical users should be sticking to. Zzmonty (talk) 10:45, 14 August 2018 (UTC)[reply]

Improved Translate - VisualEditor integration

Extension:Translate is a great tool but it does not work very well with Extension:VisualEditor. VE can not handle the ‎<translate> tags. As a result, the user can not edit text in WYSIWYG but in a little dialog box with wikitext...

This has also been reported by others more than two years ago. See:

https://phabricator.wikimedia.org/T131516: Lots of pages on mediawiki.org have "‎<translate>" and "" bits strewn about, making them hard to read and edit in source, and hard to edit in Visual Editor. Translation should not rely on making large parts of pages uneditable! Per discussion it looks like some small tweaks to VE's treatment of the extension tag may simplify things without introducing too much breakage, until a more VE-native solution is available.

https://phabricator.wikimedia.org/T55974: ‎<translate>...‎</translate> and the related ‎<tvar>...‎</tvar> are currently un-parsed and shown as plain wikitext in VisualEditor because they're not recognised, per T50891; however, once that is fixed, the blocks won't be editable except as alien nodes (in wikitext), and won't be createable. Making a proper VisualEditor plugin to translate these in-page as a rich editor shouldn't be particularly hard (he says…).

Planetenxin (talk) 15:12, 16 August 2018 (UTC)[reply]

Endorsements

Comments

Solving this issue would also have positive effect on enterprise use of MediaWiki.

Replace this line with your response.

197.156.115.144 17:52, 18 August 2018 (UTC)[reply]

Endorsements

Comments

Easier upgrade and extension manager

Comments

I use Wordpress a lot and have noticed MediaWiki is lacking somewhat when it comes to management for non-technical people compared with Wordpress, even Joomla! can do it. I have experienced the following issues:

unable to install Visual Editor with dependency of Parsoid,
initially had issues installing Semantic MediaWiki due to dependency of Composer, I did find a workaround, but not ideal,
when updating it is very frustrating having to delete all the files from the server and reloading the latest version of MediaWiki, can this not be done similar to how Wordpress ad Jooma do it?

The fact that you need access to the command line to run maintenance scripts and other functions like composer, those on shared hosting environments won't be able to do this. I am using a virtual machine with access to the command line, but I have other hosting where this is not possible. Other opensource scripts such as Wordpress and Joomla allow easier installation of extensions, is it possible that MediaWiki could follow these examples?

The server I am working on is not Internet facing, so a lot of the time I am having to take the server off line, transfer the MediaWiki installation to a local server I have built on an Internet facing machine, do what I need to do, then migrate it back over. This entire process can take two days, that's two days where my contributors are unable to contribute.

--Squeak24 (talk) 12:00, 19 August 2018 (UTC)[reply]

Endorsements

Visual Editor

Comments

I have tried to install Visual Editor a few times now, I was able to get it working without issue on my Internet facing machine, but when I tried to get it working on the server that is not Internet facing I was not able to get it working. I tried to migrate the internet facing version on my development server to my production, non-internet facing server, but for some reason it wouldn't work. It worked fine on the new pages, but not the legacy pages that require Parsoid. I tried in vain to get Parsoid working correctly on the non-internet server. Is there anyway it may be easier to use Visual Editor without Parsoid?

I did try the TinyMCE extension, this worked fine even with the old pages. Unfortunately it is still very buggy hence I was unable to have it on a production site. I want to make it as easy as possible for the contributors, I need them to edit the pages they manage, hence such a tool would be fantastic to have.

-Squeak24 (talk) 12:00, 19 August 2018 (UTC)[reply]

Endorsements

-Squeak24 (talk) 12:11, 19 August 2018 (UTC)[reply]

Full support for read protected wikis

VisualEditor is still not fully usable on read protected wikis, as Restbase does not forward authentication cookies or provide an alternative way of promotion session data. This is just an example for the neglect of wikis that do not have full access for the public. For 3rd party wikis are often read protected for valid reasons, it is an important issue to make these wikis work just as open wikis work.

Mglaser (talk) 21:32, 19 August 2018 (UTC)[reply]

Endorsements

RichardHeigl (talk) 19:50, 21 August 2018 (UTC)[reply]

Open questions

What open questions would you like to be resolved during the Wikimedia Technical Conference?

Roadmap for universal templates

A roadmap of progress intended for bundling templates with Mediawiki or whatever solves the lack of templates issue.

Rob Kam (talk) 08:51, 8 August 2018 (UTC)[reply]

Endorsements

Comments

You would need to figure out what people are using Wikipedia templates and/or templates on other sites. A person wanting to use mediawiki to create an interoffice wiki would have different needs than a person who intended to create courses with mediawiki. Zzmonty (talk) 15:44, 15 August 2018 (UTC)[reply]

I don't understand this request... if I set up a separate wiki it could contain anything, so what would be the types of templates that would make sense to include in a "universal" version? I am not shooting this down, just trying to understand - maybe I am missing something about how I could be using templates. Tenbergen (talk) 15:15, 17 August 2018 (UTC)[reply]

I am just saying that MediaWiki should look at how administrators are using MediaWiki, and what extensions / templates / modules they are including. Tenbergen, you may be right in that there might no difference in the templates to include. On the other hand, there might be a difference. For example, a person plans on no language other than English is going to have different basic needs than somebody who plans to include other languages. Do you need RTL support or asian language support? Poem is a standard function. If an administrator never plans to write poetry, there is an unneeded extension / template. Does an administrator for a business need the cute icon templates, while a person doing a fun wiki might want those templates. The same is true if a person plans to have a community of editors vs. a single editor or a small group of editors. I am thinking of the user boxes, WikiProjects, etc. Zzmonty (talk) 18:30, 20 August 2018 (UTC)[reply]

Challenges

What tasks are currently difficult for you to perform? What features are difficult to implement? What is missing or insufficient that makes it difficult: software, documentation, integration, support, something else?

Comments

Upgrading Scribunto on a shared host. Extensions that are needed to easily copy and paste existing templates should be considered critical extensions. Zzmonty (talk) 16:00, 15 August 2018 (UTC)[reply]

Better importing. For example, I need to import a txt file. Each article within the text file has a way to determine the start and end of the article. The title of the article is all in caps, and the end of the article is a bunch of ----. A way to specify rules to indicate article breaks in the txt file for import.

An easier way to figure out which components of which parts of the user interface can be edited in the mediawiki namespace would be nice. I have at times dug to find things I needed to change (e.g. errors given for a private wiki so that errors still make sense for a not-logged-in visitor), and finding where I can change things is painful. Maybe there is a good external map I just have not found, but it would be nice if this was a bit more intuitive, eg as a special page. Tenbergen (talk) 16:12, 17 August 2018 (UTC)[reply]

Do you know about "uselang=qqx"? Yaron Koren (talk) 16:29, 17 August 2018 (UTC)[reply]

@Tenbergen: Specifically, see docs at qqx trick. :) –Quiddity (talk) 04:40, 18 August 2018 (UTC)[reply]

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)[reply]

Endorsements

Comments

I would also prefer a move to GitHub --Krabina (talk) 11:51, 6 August 2018 (UTC)[reply]
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)[reply]
I find GitHub's code review interface far easier to work with than Gerrit's. James Martindale (talk) 19:04, 13 August 2018 (UTC)[reply]
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)[reply]
We successfully run on GitLab for some of our code. Its UX is very similar to GitHub's. Plus it can be run locally, is open souce and (big plus), supports cherry-picking from the interface Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]
I first got used to Gerrit (which has improved quite a bit too), and when I have used GitHub I found some things complicated (like manually resolving a conflict on merge, protected branches that block i18n updates, review comments disappearing when force-pushed). I would request a fair evaluation instead of what one is used to. Nikerabbit (talk) 08:01, 20 August 2018 (UTC)[reply]
Having extensively used Gerrit, GitHub, and GitLab, I think Gerrit is the clear winner for collaborative projects with a shared ownership model. Seeing what Debian is currently going through in the transition to GitLab (which is very close to the same feature set as GitHub), I don't think it would meet our current needs. I do agree that we should do a proper re-evaluation every so often, and work with upstream to implement our feature requests / bug fixes (shout out to Paladox and Chad here!), potentially hiring contractors if necessary. Legoktm (talk) 17:30, 22 August 2018 (UTC)[reply]

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:

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:

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)[reply]

Endorsements

Krabina (talk) 12:01, 6 August 2018 (UTC)[reply]
AdSvS (talk) 12:58, 6 August 2018 (UTC)[reply]
--[[kgh]] (talk) 11:20, 11 August 2018 (UTC)[reply]
RichardHeigl (talk) 12:09, 11 August 2018 (UTC)[reply]
(This challenge is related to my own below) Even Thorbergsen (talk) 20:28, 12 August 2018 (UTC)[reply]
--MGChecker (talk) 22:16, 13 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:23, 14 August 2018 (UTC)[reply]
·addshore· ^{talk to me!} 09:49, 14 August 2018 (UTC)[reply]
Remco de Boer 15:23, 14 August 2018 (UTC)[reply]
--Felipe (talk) 07:31, 15 August 2018 (UTC)[reply]
Ike Hecht 02:29, 16 August 2018 (UTC)[reply]
Rob Kam (talk) 08:44, 16 August 2018 (UTC)[reply]
Tenbergen (talk) 15:40, 17 August 2018 (UTC)[reply]
Tfellows (talk) 19:05, 17 August 2018 (UTC)[reply]
HakanIST (talk) 06:29, 18 August 2018 (UTC)[reply]
DuncanCrane (talk) 12:25, 18 August 2018 (UTC)[reply]

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)[reply]
for this you should look into Extension:Approved_Revs --Krabina (talk) 09:23, 10 August 2018 (UTC)[reply]

Indeed the "Lockdown" extension is more or less causing issues since MW 1.27 due to a bug apparently in core. --[[kgh]] (talk) 11:21, 11 August 2018 (UTC)[reply]
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) 11:08, 15 August 2018 (UTC)[reply]

Maybe allowing restrictions by namespace may be enough. But then if a person needs to move a page from one namespace to a different namespace, there should be an easy way to update all of the references to that page. Zzmonty (talk) 15:49, 15 August 2018 (UTC)[reply]

I have one wiki that's split private/public, and another that looks to be heading that way. It would be great if there was a very straightfwd way to designate a page public or private. Mind you, we also use SMW, and I can see where integrating properties and queries into this sort of thing would be hard. Tenbergen (talk) 15:38, 17 August 2018 (UTC)[reply]

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)[reply]

Endorsements

Yaron Koren (talk) 18:32, 6 August 2018 (UTC)[reply]
Bryandamon (talk) 18:14, 8 August 2018 (UTC)[reply]
Corey Chambers (talk) 00:12, 11 August 2018 (UTC)[reply]
--[[kgh]] (talk) 11:23, 11 August 2018 (UTC)[reply]
--MGChecker (talk) 22:16, 13 August 2018 (UTC)[reply]
— AfroThundr ^{(u · t · c)} 00:30, 14 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:35, 14 August 2018 (UTC)[reply]
·addshore· ^{talk to me!} 09:49, 14 August 2018 (UTC)[reply]
Alangi Derick (talk) 13:03, 14 August 2018 (UTC)[reply]
Remco de Boer 15:24, 14 August 2018 (UTC)[reply]
Kaldari (talk) 21:48, 14 August 2018 (UTC)[reply]
--Felipe (talk) 07:33, 15 August 2018 (UTC)[reply]
Winged Blades of Godric (talk) 10:28, 15 August 2018 (UTC)[reply]
Ike Hecht 02:26, 16 August 2018 (UTC)[reply]
Tenbergen (talk) 15:41, 17 August 2018 (UTC)[reply]
Tfellows (talk) 19:05, 17 August 2018 (UTC)[reply]
nBarto (talk) 22:48, 17 August 2018 (UTC)[reply]
HakanIST (talk) 06:29, 18 August 2018 (UTC)[reply]
DuncanCrane (talk) 12:27, 18 August 2018 (UTC)[reply]
Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]
Vedmaka (talk) 12:15, 8 September 2018 (UTC)[reply]

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)[reply]

For developers in particular, the documentation is often (usually?) missing or wrong. Sometimes developers follow the documentation and submit patches only to be corrected on code review. I wonder if there is more accurate and thorough documentation in Gerrit than in mediawiki.org. For each section of the MediaWiki code (or certain complex extensions, there seems to be a small group of developers who actually understand it. If somebody knows who these people are and has access to them, they may be able to encourage a representative of each of those groups to share their knowledge. That would make developing easier and code review more painless. --Ike Hecht 02:26, 16 August 2018 (UTC)[reply]

This is about core however there is also a big issue about extensions including the ones created and used by WMF. So we need a solution here, too.--[[kgh]] (talk) 08:19, 19 August 2018 (UTC)[reply]

Integration of an extension with VisualEditor (e.g. writing inspectors and tools, adding page options aka Magic Words or adding new toggles to the insert table dialogue) is really a lot of grepping through the code and trying to figure out how it is properly done. It this were documented better, I am sure much more extensions would have support for VisualEditor. Especially in 3rd party wikis, this would be a major improvement. Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]

Extension sustainability

For third parties it is very hard to decide if an extension is sustainable (long time experience is needed here which cannot be expected by new arrivals), e.g. is it compatible with the version of MW I use, will it be compatible or made compatible with the next version of MW, who is there to answer questions regarding its usage, who will comment on bug reports, help creating good bug reports, who is in contact with the maintainer etc. (all in due time) - somebody who is responsible for the communication around it. Thus I would like to see that every extension has a dedicated co-ordinator who will document it, answer questions and co-ordinate issue reports (not necessarily fixing the code). This may be the creator or maintainer but this is not required. However this must not be a group of people like an "editing department" or so. Currently it is a matter of chance (sometimes high, sometimes low) to get a reply. To cut it short: This person (co-ordinator) should be the documentator of the extension and at the same time the bug wrangler! In the end an extension without a co-ordinator is not sustainable and should be considered for use at ones own risk and marked as such. --[[kgh]] (talk) 08:46, 19 August 2018 (UTC)[reply]

Endorsements

Comments

Extensions being widely used but not actively maintained is a widespread issue. I suggest to have a group of people which have +2 rights on all extensions and who do have the standing and knowledge to review and merge patches submitted. Sure, all commiters with +2 on core are potential candidates, but they do not have the time to review extensions. So this should probably be a community driven process. Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]
Are you saying that the current process of granting +2 isn't community driven? In any case, there are multiple people who have +2 mostly for their work in extension maintenance. If there are people interested in doing such, they should apply for +2 rights. Legoktm (talk) 17:25, 22 August 2018 (UTC)[reply]
WordPress has a on their website an indication on which versions an extension has been tested on. Zzmonty (talk) 18:34, 20 August 2018 (UTC)[reply]

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)[reply]

Endorsements

Comments

Perhaps users don't even realise they're expected to keep their installations up to date. --Rob Kam (talk) 11:41, 15 August 2018 (UTC)[reply]

As mentioned elsewhere, if these updates were further automated or at least facilitated that would be great! Making them like Wordpress where I don't even need to touch might be too much to ask, but turning them into something where I would at least be comfortable to hand it over to a less familiar technical resource would be great. I think if I left my work environment today our wikis' software might never be updated again. Tenbergen (talk) 15:45, 17 August 2018 (UTC)[reply]

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)[reply]

Endorsements

Comments

I tried to contribute to Wikipedia, but I received threats, so I gave up. Now I am just a reader of Wikipedia, make an occasional small edit, but mostly working on my own personal wiki project.. — Preceding unsigned comment added by Zzmonty (talk) 15:53, 15 August 2018 (UTC)[reply]
Putting work into articles only to have them deleted because "not notable enough" also puts people off contributing to Wikipedia. Rob Kam (talk) 10:42, 16 August 2018 (UTC)[reply]

- I wonder if the definition of "Not notable enough" has changed since the start of Wikipedia. Unlike a regular encyclopedia, Wikipedia seems to have become a central location of general information about stuff. If I want to know the episodes of a TV series, I look at Wikipedia. If I am interested in reading about the history of school, I can usually find it on Wikipedia. What may have been considered "Not notable enough" when Wikipedia started, may not be as important today. Maybe this definition needs to be reevaluated. Zzmonty (talk) 18:40, 20 August 2018 (UTC)[reply]

Guarding against link rot

The unmaintained 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)[reply]

Endorsements

Liuxinyu970226 (talk) 01:36, 14 August 2018 (UTC)[reply]
Rob Kam (talk) 17:20, 15 August 2018 (UTC)[reply]
Tenbergen (talk) 15:50, 17 August 2018 (UTC)[reply]
--[[kgh]] (talk) 08:08, 19 August 2018 (UTC)[reply]

Comments

Would be nice if internal links to headings were included in such a feature. For a link like [[Page#heading in page]], if the heading is changed in the page, there is no way to list pages affected by that (that I know of). Tenbergen (talk) 15:50, 17 August 2018 (UTC)[reply]
Is there a bug or extension request filed for this? Legoktm (talk) 17:26, 22 August 2018 (UTC)[reply]

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)[reply]

Endorsements

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)[reply]

If whitelisting was made much easier, this would solve my public/private wiki issues as well. Putting it into LocalSettings means I can not ask a content writer to do it, it has to be a technical employee. Is there a technical reason the whitelist can't live in a namespace or special page, or riskier but more convenient, in a switch that comes up at page save time, near the "minor" and summary components? Tenbergen (talk) 15:55, 17 August 2018 (UTC)[reply]

WordPress has an extension called "restricted-site-access". It would be great if that could be added to MediaWiki as a standard extension. I used this extension on WordPress when I was making blogs for kids where I wanted to restrict who can access the blog (even read the blog) to just a few domain locations. Zzmonty (talk) 18:47, 20 August 2018 (UTC)[reply]

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)[reply]

Endorsements

PhotographerTom (talk) 17:55, 13 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:37, 14 August 2018 (UTC)[reply]
Bryandamon (talk) 06:03, 14 August 2018 (UTC)[reply]
·addshore· ^{talk to me!} 09:49, 14 August 2018 (UTC)[reply]
DuncanCrane (talk) 12:33, 18 August 2018 (UTC)[reply]
--[[kgh]] (talk) 08:10, 19 August 2018 (UTC)[reply]
Mglaser (talk) 21:48, 19 August 2018 (UTC)[reply]
...

Comments

What is needed is a template store for rather basic templates which however can get a wiki already going without the need to learn wikitext "programming". --[[kgh]] (talk) 08:10, 19 August 2018 (UTC)[reply]

Work with documents within the wiki and export pages to PDF

Many organizations come from (MSOffice)-document centric environments. Even if they gradually migrate their content to web formats, some enterprize prozesses will keep beeing heterogenoulsly document based for years. Reasons are manifold and include complinace issues, local policies, system integration, personal content review preferences, need for physical printouts at work sites and a low digital literacy of staff in mission critical positions, slowing down transition.

Mediawiki should make its embedding in heterogenous environments easy and relaxed. These workflows would include intuitive upload interface and document previews (.xlsx, .docx, .pptx) within pages and full text search indexing.

When wikis are used for technical documentation, the creation of PDF-exportable "books/article collections" also is desirable. Optimally these would embrace mixed wikitext/document collections. -- 11-G3n (talk)

Endorsements

Comments

Save article selections to different formats in the order the user selected needs to work. This would allow more use of a wiki as a workspace for later publication. This should include save as PDF, epub 3.0, HTML, doc, and otd formats.

Wikimedia doesn't really support shared hosting.

Wikimedia doesn't really support economical shared hosting. Not everyone can afford to run a wiki on the infrastructure it seems to be written for. Trying to get e.g. Visual Editor running on shared hosting is so severe a challenge that regular wiki maintainers won't even attempt it.

Rob Kam (talk) 17:18, 15 August 2018 (UTC)[reply]

Endorsements

Comments

We are also still using the old-school wiki editor because the new one is not shared hosting friendly; I haven't even looked at the visual one in months because the need to install other stuff that may or may not run on shared hosting has completely put me off. In a related way, some of the changes that were rolled out with the latest update this summer (recent changes improvements) are really neat, but they appear to have seriously slowed down parts or our wiki so I have not applied them to all our wikis yet (granted this may be an issue with our specific wiki instance, but that's how it came across to me). While the visual editor is at least a choice, some of the other changes are not, and that becomes a problem. If a new version of mediawiki needs more resources to run than the old one, that should be transparent, and ideally be in line with what shared hosting can handle. Tenbergen (talk) 16:02, 17 August 2018 (UTC)[reply]
Visual editor is definitely a huge step forward to encourage non-IT literate authors to add content to a mediawiki based site. I have to agree, though, with the author of this comment. Setting VE up in my environment defeated me, so much so we are are now using an extension that uses TinyMCE which works great for our purposes. In order for mediawiki to thrive in the future we not only need to encourage content authors by making it simple and intuitive, we also need to make it easier for new (novice) technical authors so they don't bypass mediawiki for apparently more accessible alternatives. DuncanCrane (talk) 12:47, 18 August 2018 (UTC)[reply]
Another challenge with hosted environments is that a lot of the configuration is only available by editing the LocalSettings file. It would be great if it was possible to change more settings through the mediawiki interface, in addition to user based preferences, perhaps as a special page? DuncanCrane (talk) 13:14, 18 August 2018 (UTC)[reply]
Quiete franky. I think that there is no longer an intention to support shared hosting. Probable it will be best to announce this. An open question is however how people who would like to share knowledge beyond the scope of WMF-project can do so. --[[kgh]] (talk) 08:22, 19 August 2018 (UTC)[reply]

I've had to move my simple hobbyist wiki to a wiki farm managed by others with far better resources than I'll ever have. Rob Kam (talk) 10:02, 19 August 2018 (UTC)[reply]

Considering spam and vandalism in feature design

Spam/vandalism management is harder than it needs to be due to the design of some major features, and it would be helpful if the need to address spam and vandalism was considered a critical, first-class consideration in future feature development. Tools such as the translation extension and flow, for example, obscure edits and histories and complicate the process of tracking and restoring revisions:

Translations

no history, let alone ability to revert is shown in the translation tool.
deleting translation spam/vandalism is awkward; specific translation units are not shown in a translated page's history.
no obvious way for users to indicate spam translations
reverting translation units does not fully restore the state---a removed fuzzy indicator is never restored

Talk pages/flow

edits to individual topics are mixed together, making identification of topic vandalism difficult
flow page descriptions do not have history, and multiple edits cannot be mass reverted, nor is reverting to older versions easy
flow page descriptions cannot be protected (and no progress on task T113902 has been made in 3 years)
topic titles, summaries, and visibility are trivially altered by vandals, and cannot be protected

These tools can be fixed (eventually, presumably) and/or replaced. More generally, though, easy tracking and tracing of revisions, access to histories and older revisions, and protection capabilities should be integral in the design of all features that allow user editing.

Clump (talk) 16:56, 16 August 2018 (UTC)[reply]

Endorsements

Clump (talk) 16:56, 16 August 2018 (UTC)[reply]
Rob Kam (talk) 18:47, 16 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)[reply]
Alangi Derick (talk) 20:50, 22 August 2018 (UTC)[reply]
...

Comments

Even when spam can be minimized with extension abuse filter the bots still fill the user list with noise. Rob Kam (talk) 18:47, 16 August 2018 (UTC)[reply]

stronger warnings when trying to edit old version

Our documentation process makes heavy use of the recent changes feature. Due to the breakdown by day, there is no easy way to only list a page's most recent edit, it will be listed for each day it was edited. This means that if I am away for a week, and then start reviewing changes from 7 days ago, I will likely look at a few diffs that have had additional changes since. It is easy to start editing the version that is not the current one, which is not usually what is intended. I make the mistake even though I am aware of it, and it is almost impossible to explain to less technical users that this is something to watch out for. This leads to later edits being clobbered, which is reducing buy-in in using the wiki. It would be nice if trying to edit a non-current version led to a far more "noisy" warning than that little line at the top. This might be something that I can change through interface edits, but I think the default should be more noisy in the first place. Tenbergen (talk) 16:24, 17 August 2018 (UTC)[reply]

Endorsements

Tenbergen (talk) 16:24, 17 August 2018 (UTC)[reply]
nBarto (talk) 09:01, 18 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)[reply]
...

Comments

@Tenbergen: IIUC you're asking for 2 things:

Implementation of the feature request in phab:T10681 ("Group changes across days in enhanced rc") (+1 from me!)
Making a more eye-catching default design of the core message-string MediaWiki:Editingold.
I think the difficulty there, is the message has to be skin-agnostic... I.e. able to fit in with any layout/color-scheme/design-elements/etc. You might want to look at other Wikimedia projects' designs for inspiration in tweaking your own, e.g. w:en:MediaWiki:Editingold, w:fr:MediaWiki:Editingold, w:de:MediaWiki:Editingold (3 designs, 3 implementation methods!). Or just wrap it in a few <big> tags and call it complete ;-)
@Tenbergen: Aha, I got better advice from some devs. I've filed a task at phab:T202248 ("Wrap `editingold` in a warning box to make it more visible"). :) –Quiddity (talk) 05:20, 20 August 2018 (UTC)[reply]

HTH. :) –Quiddity (talk) 03:23, 20 August 2018 (UTC)[reply]

Upgrading Scribunto

Upgrading Scribunto on a shared host. Extensions that are needed to easily copy and paste existing templates should be considered critical extensions. Zzmonty (talk) 16:00, 15 August 2018 (UTC)[reply]

Endorsements

Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)[reply]
...

Comments

Communication between pages

There is currently no satisfactory way to, when parsing a page, read data from a different page.

The PageVariable extension is experimental and appears to be no longer maintained. It is possible to achieve this with Labeled Section Transclusion, but the code will be inelegant, as it is not possible to embed <section> tags in a template. See phab:T39256 and phab:T179482.

nBarto (talk) 23:17, 17 August 2018 (UTC)[reply]

- I vote for fixing the Labeled Section Transclusion to be able to work in templates. Zzmonty (talk) 18:51, 20 August 2018 (UTC)[reply]

Endorsements

Comments

One situation where I was hoping for this functionality, is in creating more flexible page hierarchies: Organizing a set of pages using (multi-level) subpages is not very flexible: when a parent page needs to be moved, all subpages have to be moved as well. Also, it is not possible to assign multiple parent pages to one child page. By contrast, with an appropriate implementation of page variables, one could simply assign to each page a variable indicating one or more parent pages. The "breadcrumbs" containing the grandparents, great grandparents, ... can then be created by recursively reading the parent page's variable. --nBarto (talk) 23:28, 17 August 2018 (UTC)[reply]
Another use case would be when a user has a certain group, tagged information from a different page is automatically pulled into the page, to have a blended experience. e.g. Page A is a list with infos for different groups (that have different permissions), Page B describes the general workflow and depending on the group the user gets the corresponding information from Page A filled into the corresponding gaps in B

Skinning

It's 2018 and skinning still sucks.^{[thanks, Captain Obvious!]} It shouldn't be so. We should be encouraging people to write more skins and better skins, and a part of that would no doubt include making core more flexible in this regard.

Jack Phoenix _(Contact) 00:03, 20 August 2018 (UTC)[reply]

Endorsements

Comments

Making MediaWiki GDPR compliant

Setting up a GDPR compliant MediaWiki is currently a nightmare. There is a lenthy page: GDPR_(General_Data_Protection_Regulation)_and_MediaWiki_software where a lot of the hurdles are described. To be widely usable, MediaWiki should (be able to) comply with these regulations or at least support admins in achieving this. Currently this is only achievable by installing lots of different extensions and going through the GDPR themselfes, which for a lot of admins is a "no - I will just use something else then".

This could include:

dividing into username (not visible to anyone but yourself) vs displayname
explicit consent boxes
a GDPR guide and GDPR_LocalSettings.php preset to take admins by-the-hand
Let a user view all the data that a MediaWiki has on him -> XML or JASON output should be possible
Let a user delete all the data that a MediaWiki has on him (maybe with a delay to avoid abuse) -> merge deleted user's contributions to 'DeletedUser' dummyuser?
Anonymize (zeroing the last 2 tuples of) the IP on anonymous edits (immediately or after some time?)

Daniel schuerhoff (talk) 12:27, 20 August 2018 (UTC)[reply]

Endorsements

Daniel schuerhoff (talk) 12:27, 20 August 2018 (UTC)[reply]
...

Comments

Future

What features, capabilities, or use cases do you need to support in your wikis in the future that are currently missing? Try to focus on use cases rather than any specific implementation when possible. How soon do you need each and how critical is it to you?

Collaborative editing

Collaborative editing is the feature that is missing from MediaWiki.

A lot of effort has been put into the Visual Editor so it opens up MediaWiki's power to more people. The missing feature, now, is collaborative editing. With the common use of tools like Google Docs or similar tools, the absence of collaborative editing in a tool whose whole purpose is to collaboratively record and refine knowledge is unacceptable.

☠MarkAHershberger☢(talk)☣ 19:58, 3 August 2018 (UTC)[reply]

Endorsements

☠MarkAHershberger☢(talk)☣ 19:58, 3 August 2018 (UTC)[reply]
PhotographerTom (talk) 01:44, 6 August 2018 (UTC)[reply]
--Krabina (talk) 11:47, 6 August 2018 (UTC)[reply]
Susannaanas (talk) 08:58, 11 August 2018 (UTC)[reply]
RichardHeigl (talk) 12:11, 11 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:38, 14 August 2018 (UTC)[reply]
Nischayn22 (talk) 08:36, 14 August 2018 (UTC)[reply]
--Felipe (talk) 07:34, 15 August 2018 (UTC)[reply]
11-G3n (talk) 11:37, 15 August 2018 (UTC)[reply]
cscott (talk) 20:54, 16 August 2018 (UTC)[reply]
MarcvHoof (talk) 14:07, 17 August 2018 (UTC)[reply]
Tenbergen (talk) 16:04, 17 August 2018 (UTC)[reply]
Tfellows (talk) 19:06, 17 August 2018 (UTC)[reply]
Mglaser (talk) 21:51, 19 August 2018 (UTC)[reply]

Comments

True collaborative editing would be great as long as it doesn't come with additional requirements that make mediawiki less possible to run in a shared hosting environment. Alternatively, even if there were just much more noisy warnings if a page is currently being edited by someone else, that would be great. I get that we would not want someone to be able to block edits to a page by forever remaining in edit mode, and there may be other malicious ways in which a feature that actually blocks concurrent edit attempts could go wrong. But it would be nice if I had a big red message if I tried to edit something someone else currently is attempting to edit. Maybe this is more of an issue in an enterprise setting, but I have had users complain bitterly when their items get overwritten by someone who is editing at the same time. Tenbergen (talk) 16:17, 17 August 2018 (UTC)[reply]

This might be a topic of it's own, but is strongly related here: Being able to annotate or comment on parts of the text is the complementary feature to real time editing and also needed desperately. Mglaser (talk) 21:51, 19 August 2018 (UTC)[reply]

FYI, VisualEditor/Real-time_collaboration. Jamesmontalvo3 (talk) 13:17, 22 August 2018 (UTC)[reply]

Extension Package Manager

I consider a package manager for extensions to be a big need to easily installing and updating them. Especially now with the move to extension registration it would make the process of making this sort of utility easier. I am against using Composer due to the numerous bugs and issues that it has.

Alexia E. Smith (talk) 22:27, 3 August 2018 (UTC)[reply]

Endorsements

Comments

What bugs are there with using Composer to install extensions? (I mean, for those extensions that support it; obviously most do not.) Sam Wilson 01:35, 7 August 2018 (UTC)[reply]
- 1.) Both the Composer and Packagist sites set precedence on IPv6 which means if your corporate network or ISP have bad/broken IPv6 routing it requires manual workarounds to get past. 2.) Attempting to "composer update" only a single package will many times end up installing or updating unrelated packages. 3.) When composer runs into a minimum stability conflict it spews out useless errors that make debugging the issue incredibly difficult. 4.) MediaWiki ships with its own composer.json which will unintentionally overwrite local changes when updating MediaWiki. Alexia E. Smith (talk) 19:44, 14 August 2018 (UTC)[reply]
I am using mediawiki on shared hosting. Having to get additional tools working means that some shared hosting options won't be able to handle this. I think this should be an integrated tool. Tenbergen (talk) 16:06, 17 August 2018 (UTC)[reply]

Visual diffs

This would be a WYSIWYG-style display of a page diff. I'm aware that a visual diffs solution already exists, but from what I understand it's only available as a preview option within VisualEditor. It would be great to have it available in the standard page history view, even if it required VisualEditor to be installed. I've heard this feature requested by a few different MediaWiki admins.

Yaron Koren (talk) 03:09, 6 August 2018 (UTC)[reply]

Update: as someone notes below, the "VisualEditor diffs" solution can also work for regular history page diffs, and is already a beta feature on Wikimedia wikis (including this one). The documentation doesn't say that at all, as far as I can tell... anyway, I'm very glad to hear that this feature is getting implemented. Yaron Koren (talk) 13:38, 10 August 2018 (UTC)[reply]

Endorsements

Comments

On Wikimedia wikis as Beta Feature. --wargo (talk) 06:56, 8 August 2018 (UTC)[reply]

Boilerplate templates in VisualEditor

Would it be possible to choose from a number of Boilerplate templates when creating new pages when in VisualEditor? It is very helpful as a writer to be able to start with something rather than a blank page. I know the option is available in Enhanced editor through Extension:MultiBoilerplate. Ideally the editor could customize which templates he would have as options to not make the drop down list too long.

PhotographerTom (talk) 21:45, 6 August 2018 (UTC)[reply]

Endorsements

PhotographerTom (talk) 21:45, 6 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:38, 14 August 2018 (UTC)[reply]
...

Comments

Indeed, it could be very helpful and supportive for creation if the VisualEditor would be accompanied with a user friendly template choice. Either a full template or with partial template elements which can be dragged, adapted and dropped in place. MarcvHoof (talk)

Boilerplate templates would be nice in the regular editor, even, not just the visual editor. Tenbergen (talk) 16:07, 17 August 2018 (UTC)[reply]

Easier creation and editing of ImageMaps

Using the VisualEditor in enterprise wikis lowers the barrier to entry and allows much greater adoption within the company, yet there are still some features that are difficult including the ImageMap extension. Allowing users to create and edit ImageMaps directly from the VisualEditor would be a welcomed feature. Additionally, it would be nice to figure out a solution for the "Mystery meat navigation", perhaps a toggle to display the clickable areas. The following websites can be used to create ImageMaps and might be used as a reference:

Bryandamon (talk) 19:41, 10 August 2018 (UTC)[reply]

Endorsements

Bryandamon (talk) 19:41, 10 August 2018 (UTC)[reply]
Liuxinyu970226 (talk) 01:38, 14 August 2018 (UTC)[reply]
even better if it was a stand alone solution for those who can't use VE :-) DuncanCrane (talk) 13:04, 18 August 2018 (UTC)[reply]
...

Comments

I did find a page on meta that describes open source code and help pages to edit ImageMaps from within a wiki. Bryandamon (talk) 06:43, 29 August 2018 (UTC)[reply]

Job queue reports and management

There is mention of the job queue, above. Using extension Cargo I often launch jobs, e.g. to create an underlying table or a mass-search-and-replace-of-text, and it can take a long time to run (weeks, mysteriously) and some jobs seem not to finish. So I would like to get a report that lists jobs, especially those a user explicitly started, when they started, and when they finished. This might be a naive request. I do not know what information is already in the MediaWiki system about them. Some new calling back-and-forth may be necessary to give any more detailed update than that. -- Econterms (talk) 00:17, 14 August 2018 (UTC)[reply]

Endorsements

...

Comments

It would be great if there was a special page for managing queues, not just viewing them, as for example a print queue might be managed.DuncanCrane (talk) 13:07, 18 August 2018 (UTC)[reply]

Use

Bonus question: what do you use your wiki(s) for?

Implementing a workflow for document revision

In the past, the "official" documentation for a process was reviewed, sent to a printer, and then sat on shelves.

Wikis offer a speedier way to publish approved documentation and make it easily searchable. Using tools like Page Forms, Approved Revisions, and Semantic MediaWiki, a KM worker created a tool so that the appropriate people can be notified when a change has been made to some previously "approved" documentation so that they can approve the change or roll it back.

They are just rolling out this process, but it offers a way to fuse the approval process of print documentation with the flexibility and find-ability of the wiki.

☠MarkAHershberger☢(talk)☣ 20:09, 3 August 2018 (UTC)[reply]

Endorsements

Comments

We're developing a similar use case as a prototype Records Management System for a regulator. As well as maintaining an audit trail of who accesses and updates records, the workflow should support the 'governance' surrounding it including quality checks, comments and responses, and approvals. The wiki structure should also allow us to reference source information within the wiki and maintain version control when a source changes, whereby owners of records are notified if an approved source changes. We are working with Page Forms and Cargo to facilitate this and looking at options to adapt the extensions FlaggedRevs or ApprovedRevs to this environment. DuncanCrane (talk) 13:33, 18 August 2018 (UTC)[reply]

Enterprise MediaWiki

Powerpedia's mission is to help employees share information on topics while enhancing communication and coordination between DOE organizations. ^[1] -- PhotographerTom (talk) 21:52, 3 August 2018 (UTC)[reply]

semantic.wiki - A "shop window" for solutions build with Semantic MediaWiki (German only) --Planetenxin (talk) 09:24, 4 August 2018 (UTC)[reply]

KDZ (Center for Public Admninistration Research) uses a Semantic MediaWiki for project documentation, IT and process documentation and knwolege management. --Krabina (talk) 09:01, 10 August 2018 (UTC)[reply]

Urban Innovation Vienna uses a Semantic MediaWiki as a database for Projects, Publications, Persons and Institutions related to Smart Cities. --Krabina (talk) 09:01, 10 August 2018 (UTC)[reply]

City of Landsberg am Lech uses a Semantic MediaWiki for knowledge management in the citizen's service office. --Krabina (talk) 09:01, 10 August 2018 (UTC)[reply]

Atlas Copco Gas and Process (GAP) division uses MediaWiki for knowledge management. --Bryandamon (talk)

Pacific Gas & Electric (PG&E) uses MediaWiki in the Customer Care department for knowledge management. --Bryandamon (talk)

University Children's Hospital Zurich, Department of Anesthesia. Uses a SMW for clinical knowledge communication, lecture planning, airway device managment, blog/info screens, projects, contact management and other stuff. -- 11-G3n (talk) 16:16, 14 August 2018 (UTC)[reply]

Department of Internal Medicine at the University of Manitoba uses a SMW for documenting processes. Tenbergen (talk) 16:28, 17 August 2018 (UTC)[reply]

Critical Care and Medicine Database uses a public/private pair of SMWs to document just about everything about it, data structures, processes, change management, etc. Our applications help links go right into the wiki, and we are exporting from the wiki for master versions of data tables in our apps. We use it internally, and it is also where we send external people who may want to use our data. Tenbergen (talk) 16:28, 17 August 2018 (UTC)[reply]

↑ https://www.energy.gov/cio/articles/happy-8th-birthday-powerpedia

We're using mediawiki with Page Forms, Cargo (Semantic Mediawiki in an earlier version) and TinyMCE extensions for 'Lean Performance Boards' to support daily huddles in the internal risk and compliance division of a financial regulator. This documents the risks and controls and allows us to track activities assigned to members of the team and others who are responsible for managing the risks. The risks are often managed over periods of years and the wiki is also a useful repository of information of its management and status throughout its life. Individual users can see and report their individual assignments as well as teams DuncanCrane (talk) 13:44, 18 August 2018 (UTC)[reply]

Endorsements

Comments

Wiki Farm - Gamepedia

Gamepedia is a wiki farm with over 2,000 gaming related wikis. It runs a custom wiki management solution to quickly create new wikis on the fly.

List of Gamepedia Wikis

Alexia E. Smith (talk) 22:31, 3 August 2018 (UTC)[reply]

Endorsements

Liuxinyu970226 (talk) 01:39, 14 August 2018 (UTC)[reply]

Comments

We use our wiki farm currently to provide 'software as a service' solutions to different user groups. This allows different groups to share a single 'code' repository of extensions/config which supports multiple users each with their own content in a separate wiki database. We have one established group for Model Boat Clubs and are working on another for managing portfolios of project for organisations.DuncanCrane (talk) 13:50, 18 August 2018 (UTC)[reply]

Technical writing

Writing about hobbyist electronics in music (SDIY wiki). Actually on wiki farm Miraheze now because that takes away a lot of the headache of maintaining the wiki and doesn't have the garish crud that other wiki farms come with.

Rob Kam (talk) 10:05, 8 August 2018 (UTC)[reply]

Endorsements

Liuxinyu970226 (talk) 01:40, 14 August 2018 (UTC)[reply]

Comments

Wikis as Websites

MediaWiki can very well be used as regular content management system for running and maintaining websites that do not look like wikis for the users. Examples

http://www.bacid.eu - a website of a project and funding scheme Krabina (talk) 09:12, 10 August 2018 (UTC)[reply]
http://www.verwaltungspreis.at - website an Austrian public sector award Krabina (talk) 09:12, 10 August 2018 (UTC)[reply]

Endorsements

Liuxinyu970226 (talk) 01:40, 14 August 2018 (UTC)[reply]

Comments

Our user, a Model Boat Club, uses their wiki to provide a number of services to its members and the general public. The members and authors are mainly octogenarians and they are delighted that they can now maintain their website for themselves without relying on technicians to make updates for them. The site provides news feed, calendar, for sale, information, gallery and links. It also maintains a record of their race meets including the schedule and results, allowing them to compile statics relating to skippers and boats in different model classes over the years. It uses Page Forms and Semantic Mediawiki in its current public form and is currently being converted to use Cargo and the TinyMCE extension (http://phoenixmarinemodelclub.co.uk) DuncanCrane (talk) 14:02, 18 August 2018 (UTC)[reply]

Wikis as collaboration tools

The classical use case: organise content and share knowledge with people outside of your organisation.

https://www.geschichtewiki.wien.gv.at - The Vienna History Wiki provided by the Vienna city administration documenting knowledge about the city of Vienna, Austria. --Krabina (talk) 09:15, 10 August 2018 (UTC)[reply]
https://www.verwaltungspreis.at - documenting projects of municipal cooperation, mainly in Austria and Germany --Krabina (talk) 09:15, 10 August 2018 (UTC)[reply]

Endorsements

Liuxinyu970226 (talk) 01:40, 14 August 2018 (UTC)[reply]

Comments

[1] ttps://www.energy.gov/cio/articles/happy-8th-birthday-powerpedia

[1]