- A desire for a department to have "their own space" on the wiki.
In our organisation (CUSTIS, Russia) we easily solve it by creating one primary wiki + separate ones for different departments. It's just a normal wiki family with shared code. Very simple solution without any extensions. The main disadvantage is inability to search on all wikis with a single search request, but in practice I've had very little requests for this feature. So it's probably not that oftenly needed.
I'm not talking about access control
And we also have IntraACL for access control (forked from HaloACL). Still not an ideal solution, but we'll probably improve it more.
- Hierarchy. Departments want not only "their own space," they want
"subspaces" beneath it. For example, "Human Resources" wiki area with sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet. MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it "goes" since the main namespace is flat.
I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it?
- Tools for organizing large groups of articles. Categories and
namespaces are great, and the DPL extension helps a lot. But when (say) the Legal department creates 700 articles that all begin with the words "Legal department" (e.g., "Legal department policies", "Legal department meeting 2012-07-01", "Legal department lunch", etc.), suddenly the AJAX auto-suggest search box becomes a real pain for finding Legal department articles. This is SO COMMON in a corporate environment with many departments, as people try to game the search box by titling all their articles with "Legal department"... until suddenly it doesn't scale and they're stuck. I'd like to see tools for easily retitling and recategorizing large numbers of articles at once.
Recategorising is very simple with global search-and-replace. Our implementation is called BatchEditor https://github.com/mediawiki4intranet/BatchEditor
- Integration with popular corporate tools like MS Office, MS
Exchange, etc. We've spent thousands of hours doing this: for example, an extension that embeds an Excel spreadsheet in a wiki page (read-only, using a $10,000 commercial Excel-to-HTML translator as a back-end), and we're looking at embedding Exchange calendars in wiki pages next.
O_O $10000 excel-to-html? O_OOO Why not just copy-paste into for example wikEd (google://wikEd)? :-))) Not that beautiful, but it works.
- Corporate reorganizations and article titles. In any company, the
names and relationships of departments change. What do you do when 10,000 wiki links refer to the old department name? Sure, you can move the article "Finance department" to "Global Finance department" and let redirects handle the rest: now your links work. But they still have the old department name, and global search-and-replace is truly scary when wikitext might get altered by accident. Also, there's the category called "Finance department". You can't rename categories easily. I know you can do it with Pywikipedia, but it's slow and risky (e.g., Pywikipedia used to have a bug that killed <noinclude> tags around categories it changed). Categories should be fully first-class so renames are as simple as article title changes.
Mass editing tool = BatchEditor, as I've already said. But I agree that Mediawiki needs better mass editing, page selection and page exchanging (import/export) tools.
In our distribution (mediawiki4intranet) we partially solve it by implementing selection on Special:Export. BatchEditor uses this implementation when it's available. (you can see examples at http://wiki.4intra.net/Special:Export and http://wiki.4intra.net/Special:BatchEditor) (also we have an improved import/export functionality but unfortunately it's a code bomb and reworking to get it in trunk will take a lot of time...)
But it's only a partial solution, because it has no standard interface. So we also have a variation of DPL, also we have SemanticMediaWiki. And all of them has partially the same - but not totally the same - functionality. And it would be good if there existed a single, standartized, optimised and cacheable method of page selection.