Dear Mark. I type my opinion on your request. 1. About me. I handle the mizugadro.mydns.jp/t It seems to work well during almost two years. It is not perfect: Sometimes, the text disappears after the closing references; Sometimes the tumbnail for a picture fails; I could not make work the "short name" service, Include of PDF files hapened to be different from that for other files and difficult to handle; Construction and customing of the skins also happened to be difficult; I could not handle the antispam service (I locked the self-authorization), I doubt, if they can be reproduced by colleagues; so, I do not report them. In general, I am glad, that the configuration I could arrange with your help works and I am glad, that I can use it without to enter again into details of php, html, mysql and other things. But for the case, if the point of view of a diletant helps you, I type some comments below. 2. Most important extensions: Mathjax, Poem (I use it to include the codes into the wiki-text) Service for references, Service for uploading umages (I do not remember the names of these extensions). I should appreciate the extension to provide the "short name", if it will be installed by itself, authomatically, just answering "yes" at the installing. At least two years ago, the handling requested a lot knowledge. Few years ago, for me, it was a shoke, when first time I realized, that the most of services, installed and configured at the widely known vikis (wikipedia, citizendium, etc) are not supported by default. I believed them to be parts of the core; then it happened that they are only extensions, and each of them requires some handling at the installation. The same refers to caching. I do not undertand, why is it so difficlut, that each time it should be handled manually. 2. Independence. Often, trying to improve some thing in the set-up, I saw, that I destroy some other thing. I know, how difficul is to provide the independence, but it is very important. You cannot underestimate the stupidity of the beginner, who deals with a big large package, knowing close to nothing about it, with the naive hope, that the professionals did their job, and the rest is just to plug and to use. 3. Compatibility. Often the symbols, formatting, formulas, that appear fine at one computer, look ugly at another computer. I do not know, if anything can be done about this. 4. Descriptions. When I begun to deal with mediawiki, my first impression was, that the descriptions are written in some strange, unknown to me language, slightly similar to English. It may have sense to count, how many new terms shoud the beginner learn, in order to understand the description. 5. About errors. The beginner does not know the origin of the errors: is it a defect of the internet service, or some fault in the setting of the router, or that of a server, or something is wrong with mysql, or with some configuration files, it is due to a mediawiki bug. The first impression is "Everything was working, and then - nothing". I think, these instructions should begin with very beginning: A. Check that your computer is connected to the electric plug. B. Check that your monitor, keyboard and mouse are connected to the computer. C. Check that your compiter is "on" (type "help" in the command line.) D. Check, that ... – and so on. I exaggerate a bit, but, I hope, you understand this point. 6. Instructions. Usually, the most difficult for the beginner is to understand, what tools are necessary for his/her goals. In the internet, there is tradition, that every package clams, that namely it can satisfy the needs of the user. Usually, the package tries to form these needs, instead. I think, mediawiki could be good exception. Over-vice, you get questions like "What scissors are better to hummer this screw into a wall?" Sometimes, the user does not know even the generic names of the tools necessary. 7. Options and setting. The configuration files seem to be designed, optimized for the needs of the authors of the software, not for the needs of the users. Usually, the arbitrary variation of a parameter leads to some non-working configuration. I do not know, how to organize it better; may be, my needs are different from those of the most of users. But still, you may imagine some diletant, who tries various options in order to get the result by the method of probes and errors.. So, keep in mund the question: What will be, if some stupid admin changes this option? I see, this had improved since previous versions of mediawiki, but I think, it still can be improoved. All the above are just my personal impressions. Sorry, if I misunderstand the request below. ================================ On Mon, 26 Jan 2015, Mark A. Hershberger wrote:

Mark H. asks: My team runs a successful internal wiki at Vistaprint/Cimpress, with several thousand users, 200,000 pages, and ~80 custom extensions. Some suggested areas of focus: 1. VisualEditor, as others have said. Making it as easy to use & maintain as possible. Also make it easy to port WikiEditor extensions to work with VisualEditor. 2. Categories. All they give you today is a list of alphabetical links (on a category page), 200 at a time. They could be & do so much more. How about: (a) Renaming a category: make it a simple operation for the user. Pywikibot is a poor substitute (and frequently has destructive bugs regarding category renames, like this recurring one: https://phabricator.wikimedia.org/T57315) (b) Search within a category. (Including transcluded category tags, which Lucene cannot handle with its "incategory" keyword.) (c) Search within category and all its subcategories, recursively. 3. Namespaces. Right now they are irrevocably tied to article titles, so you're forced to begin your title with "Namespace:...". That's like forcing all Linux users to use absolute pathnames whenever they create a file. :-) Provide a way to "cd" into a namespace and stay there... making it your default namespace when creating articles. Or something equivalent. Let articles exist "in" a namespace without forcing authors to title their articles in a particular way. Here's why. In a company, different departments want to "own" different parts of a wiki: setting a different look & feel, limiting edit privileges to a group, etc. The only mechanism provided by Mediawiki for this is the namespace. But then every user needs to remember to title their articles specially. Hope this helps, DanB ________________________________ My email address has changed to danb(a)cimpress.com. Please update your address book. Cimpress is the new name for Vistaprint NV, the world’s leader in mass customization. Read more about Cimpress at www.cimpress.com. ________________________________

Another suggestion: given a piece of text in the wiki, make it easy to identify the person who modified it last. Like an "svn blame" for wiki article. DanB ________________________________ My email address has changed to danb(a)cimpress.com. Please update your address book. Cimpress is the new name for Vistaprint NV, the world’s leader in mass customization. Read more about Cimpress at www.cimpress.com. ________________________________

I sysadmin a few internal and one external wiki at work, and also rationalwiki.org. One of the work wikis is SMW. For the work wikis, OH GOD I WANT VE. Our users are normal competent people who aren't so good with computers. But they can work a word-processorish rich text editor just fine. For this use case, even VE without wikitext (just HTML backing) would be fantastic. (Maybe a one-off converter for the legacy wikitext?) For the RationalWiki side, things are great actually. My main headache there is a pile of in-house extensions that I don't understand and make me look to our forthcoming 1.19->1.23 upgrade with some trepidation. My other main headache is a pile of content in LQT that I would dearly like to extract from LQT; so please please please make a robust migration path from LQT to Flow, when Flow is finished. In both cases, installing later versions of stuff, node.js, etc. is just fine for our use case. - d.