On 6 February 2013 23:58, Tim Starling tstarling@wikimedia.org wrote:
I think we can turn MediaWiki into a fully featured wiki engine which can compete with the likes of Confluence. I don't think it can ever compete with TiddlyWiki or UseModWiki in their respective niches.
(veering slightly off topic)
What in Confluence are you thinking of MediaWiki as lacking?
The main two in my experience are (1) firm access control (2) WYSIWYG editor. (1) is just not something MW can promise to do securely unless pretty much every developer cared and (2) is on the way (certainly before the end of time). Any others of importance?
[ps: Confluence is horrible and its hardware requirements do in fact make MediaWiki look lightweight.]
- d.
On 07/02/13 11:05, David Gerard wrote:
What in Confluence are you thinking of MediaWiki as lacking?
The main two in my experience are (1) firm access control (2) WYSIWYG editor. (1) is just not something MW can promise to do securely unless pretty much every developer cared and (2) is on the way (certainly before the end of time). Any others of importance?
MediaWiki has internal interfaces which support fine-grained write permissions right down to the level of individual pages edited by individual users. Consider how fine-grained AbuseFilter is, for example. These interfaces are old and are used by everything. So for write permissions, any ACL model you can think of can be slapped on top as an extension and will be robust.
For read permissions, the options are coarser, but whitelist read wikis are reasonably secure, even in the presence of naively written extensions, since the usual entry points (API, RL, action=ajax, special pages) are restricted by default.
Wikimedia uses whitelist-read wikis for all sorts of sensitive data. The usual approach is to separate private data with different audiences into different wikis. That would be more feasible for small sites if multi-wiki installation and management was easier.
So I don't think the situation with access control is as bad as people make out.
For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.
This is not something WMF is interested in doing, that has been made extremely clear in the last year.
-- Tim Starling
Hey,
For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.
This is not something WMF is interested in doing, that has been made extremely clear in the last year.
Agree, I also think this is the main issue, and know other people active with MW outside WMF think the same.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
(Added MW-Enterprise mailing list)
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.
Totally agreed.
I (along with a few other hardy volunteers) have been helping MW users at [[mw:Project:Support desk]] and it seems clear that the focus most developers have on the WMF use case has really made MW less usable for other people.
One of my clients had an older (1.11) MediaWiki installation that they are using to share information with their distributors world-wide. Their first attempt to get the system to do what they wanted was a flop since the Java developer they had working on the system really didn't know that much about MW. I was able to get the system upgraded to 1.19 and adapt MW to their infrastructure using hooks, ResourceLoader, and pages they could update in the "MediaWiki" namespace.
So, yes, I think MediaWiki has a lot to offer corporate users, but we haven't really made that clear or shown them how to do a lot of things they want to do.
Tim has it right when he says MediaWiki "needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over."
We've discussed this sort of thing over and over, but I think we're actually beginning to make some headway now thanks especially to work by Mariya Miteva.
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.
I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia: The main reason we chose Confluence was lack of
Totally agreed.
I (along with a few other hardy volunteers) have been helping MW users at [[mw:Project:Support desk]] and it seems clear that the focus most developers have on the WMF use case has really made MW less usable for other people.
One of my clients had an older (1.11) MediaWiki installation that they are using to share information with their distributors world-wide. Their first attempt to get the system to do what they wanted was a flop since the Java developer they had working on the system really didn't know that much about MW. I was able to get the system upgraded to 1.19 and adapt MW to their infrastructure using hooks, ResourceLoader, and pages they could update in the "MediaWiki" namespace.
So, yes, I think MediaWiki has a lot to offer corporate users, but we haven't really made that clear or shown them how to do a lot of things they want to do.
Tim has it right when he says MediaWiki "needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over."
We've discussed this sort of thing over and over, but I think we're actually beginning to make some headway now thanks especially to work by Mariya Miteva.
There is no path to peace. Peace is the path. -- Mahatma Gandhi, "Non-Violence in Peace and War"
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Sorry about that - Gmail reload glitch
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.
I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia (which has since been abandoned):
http://www.theregister.co.uk/2007/03/13/disney_eisner/ http://family.go.com/parenting/
The main reasons we chose Confluence:
* An easier to understand API. This seems to not be a problem any more: http://www.mediawiki.org/wiki/API:Client_code * Easier setup on Windows: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly made easier now by Bitnami: http://bitnami.org/stack/mediawiki
Do we have a place where people can talk through problems with corporate adoption? I suspect Tim's correct about the general case but that focusing on specifics would drive adoption.
Dan
Hi Dan,
We have http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion where we've been discussing some MW user issues, but the dicussion was not focused on corporate per se. We can use the same page or maybe set up a subpage if you think it will be easier. There is also https://www.mediawiki.org/wiki/Enterprise_hub. If anyone know of another appropriate place, please share.
I would be glad to see such a space set up and discussion going on and would be happy to assist with that.
Mariya
On Thu, Feb 7, 2013 at 7:06 PM, Dan Andreescu dandreescu@wikimedia.orgwrote:
Sorry about that - Gmail reload glitch
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some
particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.
I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia (which has since been abandoned):
http://www.theregister.co.uk/2007/03/13/disney_eisner/ http://family.go.com/parenting/
The main reasons we chose Confluence:
- An easier to understand API. This seems to not be a problem any more:
http://www.mediawiki.org/wiki/API:Client_code
- Easier setup on Windows:
http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly made easier now by Bitnami: http://bitnami.org/stack/mediawiki
Do we have a place where people can talk through problems with corporate adoption? I suspect Tim's correct about the general case but that focusing on specifics would drive adoption.
Dan _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 7 February 2013 17:06, Dan Andreescu dandreescu@wikimedia.org wrote:
I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia (which has since been abandoned): The main reasons we chose Confluence:
- An easier to understand API. This seems to not be a problem any more:
http://www.mediawiki.org/wiki/API:Client_code
- Easier setup on Windows:
http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly made easier now by Bitnami: http://bitnami.org/stack/mediawiki
yeah, I was speaking from my experience of MW vs Confluence, where the deciders were (1) no WYSIWYG and slightly (2) none of the fancy ACL stuff Confluence has. The ACLs were more a theoretical selling point to the business decision maker, but WYSIWYG swung it I think. And the users *hated* Confluence, but at least they didn't have to deal with Wikitext.
(In my current job I'm happily spreading MediaWikis far and wide, albeit with very little customisation. But I'm really keen to use the Visual Editor as soon as it's in a tarball version.)
- d.
On Thu, Feb 7, 2013 at 11:45 AM, David Gerard dgerard@gmail.com wrote:
(In my current job I'm happily spreading MediaWikis far and wide, albeit with very little customisation. But I'm really keen to use the Visual Editor as soon as it's in a tarball version.)
Yes, that is the prime reason we're still on 1.17 at work, it's the most recent version the FCKEditor extension works on. Soon as there's something equivalent for current versions they *might* consider upgrading.
Yes, that is the prime reason we're still on 1.17 at work, it's the
most recent version the FCKEditor extension works on.
@Admins who use FCKEditor: please be reminded that be reminded, that FCKEditor has severe security issues.
On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries mail@tgries.de wrote:
@Admins who use FCKEditor: please be reminded that be reminded, that FCKEditor has severe security issues.
Yes, but as I mentioned until there is a suitable replacement, your choices are: run an insecure wiki, not use mediawiki.
Am 07.02.2013 21:46, schrieb OQ:
On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries mail@tgries.de wrote:
@Admins who use FCKEditor: please be reminded that be reminded, that FCKEditor has severe security issues.
Yes, but as I mentioned until there is a suitable replacement, your choices are: run an insecure wiki, not use mediawiki.
Use mediawiki, but do not use FCKEditor. see http://www.cvedetails.com/vulnerability-list/vendor_id-2724/Fckeditor.html Multiple directory traversal vulnerabilities in FCKeditor before 2.6.4.1 allow remote attackers to create executable files in arbitrary directories via directory traversal sequences in the input to unspecified connector modules, as exploited in the wild for remote code execution in July 2009, related to the file browser and the editor/filemanager/connectors/ directory.
Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system internally. 150,000+ topics, 1000+ active users across several continents, five years of history, and a fully supported team of developers to create extensions. (We are looking into open-sourcing some of them.)
The main requests from our corporate users are:
0. WYSIWIG editor. No surprise here.
1. A desire for a department to have "their own space" on the wiki. I'm not talking about access control, but (1) customized look & feel, and (2) ability to narrow searches to find articles only within that space. The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax "NamespaceName:SearchString". However, this is not a pleasant solution, because it's cumbersome to precede every article title with "NamespaceName: " when you create, link, and search.
If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level). I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc.
Some way to search within categories reliably would also be a huge win. Lucene provides "incategory:" but it misses all articles with transcluded category tags.
2. 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?
3. 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.
4. 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.
5. 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.
Hope this was insightful/educational... DanB
I don't mind these discussions, but can we please stop changing the subject, because it's changed three times and it makes it difficult to keep track of.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
----- Original Message -----
From: "Daniel Barrett" danb@VistaPrint.com
- A desire for a department to have "their own space" on the wiki.
I'm not talking about access control, but (1) customized look & feel, and (2) ability to narrow searches to find articles only within that space. The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax "NamespaceName:SearchString". However, this is not a pleasant solution, because it's cumbersome to precede every article title with "NamespaceName: " when you create, link, and search.
If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level). I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc.
Some way to search within categories reliably would also be a huge win. Lucene provides "incategory:" but it misses all articles with transcluded category tags.
- 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?
What you want, I think, is what Zope2 called "acquisition". It's like OO subclass inheritance, but it's *geographic* depending on where you were in the tree; the old Mac Frontier system did something like it too.
You want links to have a Search Path, that starts with whatever part/ subpart of the tree the current page is in, and then climbs the tree, ending in the unadorned Main namespace, whenever a user clicks them.
That breaks the semantics of wikilinks some, but that's probably ok for your use. It *might* be generally useful; I'm trying to figure out if there are any obvious common use cases that it breaks, and how you tell where in the tree a page lives when it's created (and how you would show that to users).
Cheers, -- jra
Hi Dan,
thanks a lot for the insights to the vistaprint MediaWiki ecosystem.
Did you give Semantic MediaWiki a try?
/Alexander
Am 07.02.2013 22:31, schrieb Daniel Barrett:
Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system internally. 150,000+ topics, 1000+ active users across several continents, five years of history, and a fully supported team of developers to create extensions. (We are looking into open-sourcing some of them.)
The main requests from our corporate users are:
WYSIWIG editor. No surprise here.
A desire for a department to have "their own space" on the wiki. I'm not talking about access control, but (1) customized look& feel, and (2) ability to narrow searches to find articles only within that space. The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax "NamespaceName:SearchString". However, this is not a pleasant solution, because it's cumbersome to precede every article title with "NamespaceName: " when you create, link, and search.
If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level). I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc.
Some way to search within categories reliably would also be a huge win. Lucene provides "incategory:" but it misses all articles with transcluded category tags.
- 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.
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.
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.
Hope this was insightful/educational... DanB _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
- 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.
vitalif@yourcmc.ru writes:
In our organisation (CUSTIS, Russia) we easily solve it by creating one primary wiki + separate ones for different departments.
In practice, we have found this doesn't work well for us (with thousands of employees). Each department winds up writing its own wiki page about the same topic (say, Topic X), and they're all different. Users don't know which one is the "real" or "right" article. We find it better to have one central wiki with one definitive article per topic. No redundancy, no coupling, and no version skew between wikis.
Recategorising is very simple with global search-and-replace. Our implementation is called BatchEditor https://github.com/mediawiki4intranet/BatchEditor
Thanks, I'll check it out. Categorization can get very complicated on a MediaWiki system though. Consider this fairly simple template example:
{{#if:{{{department|}}} | [[Category:{{{department}}} projects]]}}
I would be amazed if any global search-and-replace could handle this!
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.
Now, I will demonstrate what I mean by "Corporate needs are different." :-)
With our extension, the Excel spreadsheet is rendered "live" in the wiki page. So if somebody updates the spreadsheet (on a network drive), the wiki page is automatically and instantly up to date! This is totally different from a one-time copy-and-paste, and much more maintainable. (And it's pretty fast too, with AJAX and good caching.)
Even better, if your spreadsheet generates a graph or chart, the image gets embedded in the wiki page too, and is automatically kept up to date. And if your spreadsheet calls out to a database for its data, to generate the chart, then the wiki is updated when the database changes too! Suddenly, MediaWiki has all the charting capability of Excel + SQL. This is very powerful and definitely worth $10K for a highly analytical company like ours.
We've had this feature for about 2 months, and so far we have 350+ articles with embedded spreadsheets, updated "live."
also we have SemanticMediaWiki.
We started looking into Semantic MediaWiki - it has impressive features. But we got scared off by stories that it slows down the wiki too much. Maybe we should give it another look.
DanB
On 02/08/2013 01:23 PM, Daniel Barrett wrote:
also we have SemanticMediaWiki.
We started looking into Semantic MediaWiki - it has impressive features. But we got scared off by stories that it slows down the wiki too much. Maybe we should give it another look.
DanB
A recent improvement in SMW is the new database structure for Semantic MediaWiki, SMWSQLStore3 -- this makes SMW faster and more efficient.
http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.8
It got released 2 December 2012. So yeah, check it out.
(Shout-out to Nischay Nahata who led that work as his 2012 Summer of Code project.)
On 2013-02-08 2:28 PM, "Sumana Harihareswara" sumanah@wikimedia.org wrote:
On 02/08/2013 01:23 PM, Daniel Barrett wrote:
also we have SemanticMediaWiki.
We started looking into Semantic MediaWiki - it has impressive features. But we got scared off by stories that it slows down the wiki too much. Maybe we should give it another look.
DanB
A recent improvement in SMW is the new database structure for Semantic MediaWiki, SMWSQLStore3 -- this makes SMW faster and more efficient.
http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.8
It got released 2 December 2012. So yeah, check it out.
(Shout-out to Nischay Nahata who led that work as his 2012 Summer of Code project.)
-- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I know nothing of smw, but surely using an rdf store backend ( which from what i understand has been supported for quite some time) would be more efficient than a relational db backend, no matter how optimized that backend might be.
-bawolff
Hey,
We started looking into Semantic MediaWiki - it has impressive features.
But we got scared off by stories that it slows down the wiki too much. Maybe we should give it another look.
You _can_ abuse SMW in a way that it will kill performance on your wiki. If you use it in a sane fashion, it does not greatly affect performance. Sure there is room for improvement in some places, though it is certainly nowhere near being unusable due to performance issues, as i clearly demonstrated by many people using it very effectively. So though such stories due have a kernel of truth, they tend to be propagated by people not really knowing what they are talking about and tend to portray things bleaker then they actually are.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On 02/08/2013 10:23 AM, Daniel Barrett wrote:
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.
Now, I will demonstrate what I mean by "Corporate needs are different." :-)
With our extension, the Excel spreadsheet is rendered "live" in the wiki page. So if somebody updates the spreadsheet (on a network drive), the wiki page is automatically and instantly up to date! This is totally different from a one-time copy-and-paste, and much more maintainable. (And it's pretty fast too, with AJAX and good caching.)
Even better, if your spreadsheet generates a graph or chart, the image gets embedded in the wiki page too, and is automatically kept up to date. And if your spreadsheet calls out to a database for its data, to generate the chart, then the wiki is updated when the database changes too! Suddenly, MediaWiki has all the charting capability of Excel + SQL. This is very powerful and definitely worth $10K for a highly analytical company like ours.
We've had this feature for about 2 months, and so far we have 350+ articles with embedded spreadsheets, updated "live."
As an aside, you could almost certainly do this cheaper with WorkingWiki. If you can write a make rule to retrieve the Excel file from the network drive and make it into html and image files (and maybe a little wikitext to format the page), you're done.
LW
Le 08/02/13 21:51, Lee Worden a écrit :
As an aside, you could almost certainly do this cheaper with WorkingWiki. If you can write a make rule to retrieve the Excel file from the network drive and make it into html and image files (and maybe a little wikitext to format the page), you're done.
In big companies, 10 000$ is cheap. Plus I bet they get a support contract coming in. Overall, that is probably cheaper than paying an internal software developer to integrate and then maintain the WorkingWiki solution.
On 08/02/13 21:51, Lee Worden wrote:
As an aside, you could almost certainly do this cheaper with WorkingWiki. If you can write a make rule to retrieve the Excel file from the network drive and make it into html and image files (and maybe a little wikitext to format the page), you're done.
LW
You could do it with openoffice.org/libreoffice, although I agree that getting all the dependencies right for running in the server is a bit tedious. You can also use Excel itself for that (eg. COM automation), as suggested by vitalif, supposing you are using a Windows server.
On 9 February 2013 23:00, Platonides Platonides@gmail.com wrote:
You could do it with openoffice.org/libreoffice, although I agree that getting all the dependencies right for running in the server is a bit tedious. You can also use Excel itself for that (eg. COM automation), as suggested by vitalif, supposing you are using a Windows server.
You can in fact automate OO/LO in this manner. We do this at work (an application that has to turn RTF and DOC into PDFs; if you want a fighting chance of rendering Word files, you need something of comparable size to Word). Not fast (and we never could get daemon mode working) so cache your results.
- d.
On 02/09/2013 03:00 PM, Platonides wrote:
On 08/02/13 21:51, Lee Worden wrote:
As an aside, you could almost certainly do this cheaper with WorkingWiki. If you can write a make rule to retrieve the Excel file from the network drive and make it into html and image files (and maybe a little wikitext to format the page), you're done.
LW
You could do it with openoffice.org/libreoffice, although I agree that getting all the dependencies right for running in the server is a bit tedious. You can also use Excel itself for that (eg. COM automation), as suggested by vitalif, supposing you are using a Windows server.
Yes, something like that is what I had in mind.
On 02/09/2013 11:06 AM, Antoine Musso wrote:
In big companies, 10 000$ is cheap. Plus I bet they get a support contract coming in. Overall, that is probably cheaper than paying an internal software developer to integrate and then maintain the WorkingWiki solution.
-- Antoine "hashar" Musso
True. Others who operate less formally might find it a welcome option, OTOH. LW
Platonides (and others) offered comments like:
You could do [Excel to HTML] with openoffice.org/libreoffice, although I agree that getting all the dependencies right for running in the server is a bit tedious. You can also use Excel itself for that (eg. COM automation), as suggested by vitalif...
My team investigated several Excel-to-HTML solutions, including openoffice.org, Excel itself, a free converter on Google Code, etc. The clear winner was Aspose (www.aspose.com), running under Mono, for ease of automation with MediaWiki and quality of results. Relatively expensive but it works great.
DanB
The bad thing about corporate users is that have special needs, the good thing is that are willing to pay for a service. Maybe somebody should start selling that service (in the form of a "package", "mediawiki distro", or other mode).
My company uses GoogleDocs, but we are developers, so we don't have the mindset of the people that share photos inside .doc files. Apparently you can embed googledocs in html. http://en.support.wordpress.com/google-docs/
It would be natural for us to find a way to embed google docs in a wiki,... but we don't need to, because a simple link is enough.
In practice, we have found this doesn't work well for us (with thousands of employees).
Yeah, our company doesn't have thousands of employees :-)
Each department winds up writing its own wiki page about the same topic (say, Topic X), and they're all different.
So it means most of your departments work on something very similar? Probably we don't have this problem because our departments and projects strongly differ, so everyone just writes their specific articles to their own wikis and general information to the primary "CustisWiki". We have ~7 wikis for the whole company (~200 employees).
Users don't know which one is the "real" or "right" article. We find it better to have one central wiki with one definitive article per topic. No redundancy, no coupling, and no version skew between wikis.
Just an idea - you can also setup the replication process between wikis to ease fighting
Thanks, I'll check it out. Categorization can get very complicated on a MediaWiki system though. Consider this fairly simple template example:
{{#if:{{{department|}}} | [[Category:{{{department}}} projects]]}}
I would be amazed if any global search-and-replace could handle this!
Such examples of course are much harder, but if there is not much chaos, you can handle it with regexps... Not a task for an average user, but he can ask someone who knows regexps to do it :-)
With our extension, the Excel spreadsheet is rendered "live" in the wiki page.
Ooh, I see, of course it's a big feature! Also another question - didn't you try to use some automation using excel itself to save xls as an html?
We started looking into Semantic MediaWiki - it has impressive features. But we got scared off by stories that it slows down the wiki too much. Maybe we should give it another look.
As someone already said, it should not affect performance noticeably if you don't abuse it. And also, even if use abuse it - it has a very good feature: "concept caching", i.e. caching of semantic query results with correct invalidation (as I understand it has some limitations though). (http://semantic-mediawiki.org/wiki/Help:Concept_caching)
Overall, it's very nice to see that a big company like yours has successful MediaWiki usage experience (I assume it's successful, yeah? :))
Do you have any extensions or modifications that you would like to make public & free & open source? Or maybe you even already did it with something? :-)
Each department winds up writing its own wiki page about the same topic (say, Topic X), and they're all different.
So it means most of your departments work on something very similar?
Not exactly. Each team treats its wiki as "The" wiki, and they create general-purpose articles like "How to request a day off from your manager" and "Where is the company cafeteria" that apply to the whole company. Individual writers do not think about the big picture, that general-purpose articles might belong a different, general-purpose wiki. They just want to get their job done quickly. So these kinds of articles get written in the wrong wiki, or in several wikis at once, and they drift out of sync. With a single, central wiki, this is much less likely.
Imagine if Wikipedia had a separate wiki for every city in the world. The same problem would result.
Do you have any extensions or modifications that you would like to make public & free & open source? Or maybe you even already did it with something? :-)
Indeed, we are working out a way to open-source some of our extensions.
DanB
On 02/11/2013 11:25 AM, Daniel Barrett wrote:
Imagine if Wikipedia had a separate wiki for every city in the world. The same problem would result.
I find it is easier to imagine what would happen if each language had a separate Wikipedia. We would end up with slightly different facts maintained on each wiki.
Imagine the chaos!
;)
On 02/12/2013 05:30 PM, Mark A. Hershberger wrote:
On 02/11/2013 11:25 AM, Daniel Barrett wrote:
Imagine if Wikipedia had a separate wiki for every city in the world. The same problem would result.
I find it is easier to imagine what would happen if each language had a separate Wikipedia. We would end up with slightly different facts maintained on each wiki.
Come on, this will be a similar discussion of what is the NPOV concerning the Falkland island on the English and the Spanish Wikipedia. IMHO each community should organize his wiki on it's own. Meta, Mediawiki, Commons and Wikidata already have interlanguage-communities and I think this doesn't work bad.
Wikidata will be a bit different because it will integrate itself into the wikis' structures. Therefore I think that there will be discussion. So it's really great that the developers let the consumers the choice if they wanted to use wikidata or not.
Cheers
Marco
On 2013-02-13 11:27 AM, "Marco Fleckinger" marco.fleckinger@wikipedia.at wrote:
On 02/12/2013 05:30 PM, Mark A. Hershberger wrote:
On 02/11/2013 11:25 AM, Daniel Barrett wrote:
Imagine if Wikipedia had a separate wiki for every city in the world.
The same problem would result.
I find it is easier to imagine what would happen if each language had a separate Wikipedia. We would end up with slightly different facts maintained on each wiki.
Come on, this will be a similar discussion of what is the NPOV concerning
the Falkland island on the English and the Spanish Wikipedia. IMHO each community should organize his wiki on it's own. Meta, Mediawiki, Commons and Wikidata already have interlanguage-communities and I think this doesn't work bad.
Wikidata will be a bit different because it will integrate itself into
the wikis' structures. Therefore I think that there will be discussion. So it's really great that the developers let the consumers the choice if they wanted to use wikidata or not.
Cheers
Marco
I think you missed the point of the previous email.
-bawolff
Hi everyone,
I guess this would not directly solve any of the problems listed, but would it be helpful to bring back to life https://www.mediawiki.org/wiki/Enterprise_hub ? It was started by somebody an year or two ago but seems to have been abandoned at a draft stage. I am thinking if everybody adds some information about extensions/pages they find particularly useful in the enterprise world, it will help future users but also help current enterprise wikis exchange experience. Does this seem worthwhile?
Mariya
On Wed, Feb 13, 2013 at 11:38 PM, Brian Wolff bawolff@gmail.com wrote:
On 2013-02-13 11:27 AM, "Marco Fleckinger" marco.fleckinger@wikipedia.at wrote:
On 02/12/2013 05:30 PM, Mark A. Hershberger wrote:
On 02/11/2013 11:25 AM, Daniel Barrett wrote:
Imagine if Wikipedia had a separate wiki for every city in the world.
The same problem would result.
I find it is easier to imagine what would happen if each language had a separate Wikipedia. We would end up with slightly different facts maintained on each wiki.
Come on, this will be a similar discussion of what is the NPOV concerning
the Falkland island on the English and the Spanish Wikipedia. IMHO each community should organize his wiki on it's own. Meta, Mediawiki, Commons and Wikidata already have interlanguage-communities and I think this doesn't work bad.
Wikidata will be a bit different because it will integrate itself into
the wikis' structures. Therefore I think that there will be discussion. So it's really great that the developers let the consumers the choice if they wanted to use wikidata or not.
Cheers
Marco
I think you missed the point of the previous email.
-bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I guess this would not directly solve any of the problems listed, but would it be helpful to bring back to life https://www.mediawiki.org/wiki/Enterprise_hub ? It was started by somebody an year or two ago but seems to have been abandoned at a draft stage. I am thinking if everybody adds some information about extensions/pages they find particularly useful in the enterprise world, it will help future users but also help current enterprise wikis exchange experience. Does this seem worthwhile?
IMHO there are so much useful extensions that I think it can be a little much for that page.
For example if I edited that article I would put almost all extensions from our distribution there... so I'm documenting them on http://wiki.4intra.net/Category:Mediawiki4Intranet_extensions :-)
On 14.02.2013 21:14, vitalif@yourcmc.ru wrote:
I guess this would not directly solve any of the problems listed, but would it be helpful to bring back to life https://www.mediawiki.org/wiki/Enterprise_hub ? It was started by somebody an year or two ago but seems to have been abandoned at a draft stage. I am thinking if everybody adds some information about extensions/pages they find particularly useful in the enterprise world, it will help future users but also help current enterprise wikis exchange experience. Does this seem worthwhile?
IMHO there are so much useful extensions that I think it can be a little much for that page.
For example if I edited that article I would put almost all extensions from our distribution there... so I'm documenting them on http://wiki.4intra.net/Category:Mediawiki4Intranet_extensions :-)
The question is, how much they are stable and secure. MediaWiki is high-quality software that should not be impaired by low-quality extension. Also, when extension is unmaintained, it's stability and security becomes questional as well. Also, I remember for major MW extensions scalability is the big problem. Efficient SQL queries, using APC / Memcached cache, not invalidating parser cache too often. For example my own Extension:QPoll is not well-scaling requiring some major rewrites. That applies to many of another extensions as well. Dmitriy
Hi,
There are so many extensions useful to the enterprise but probably also so many which are not useful at all or not maintained and if I wanted to start a corporate wiki right now I would probably be very lost what to look at and how people do things, so it seemed like a good idea to list the extensions that ARE actually used. Also, I guess one team solved a certain problem one way, while another solved it differenty, using a different extension or set of extensions, so writing this out might help everybody get new ideas/ avoid reinventing the wheel. But I guess I either asked on the wrong list or there is not much interest at all.
Mariya
On Thu, Feb 14, 2013 at 9:06 PM, Dmitriy Sintsov questpc@rambler.ru wrote:
On 14.02.2013 21:14, vitalif@yourcmc.ru wrote:
I guess this would not directly solve any of the problems listed, but
would it be helpful to bring back to life https://www.mediawiki.org/**wiki/Enterprise_hubhttps://www.mediawiki.org/wiki/Enterprise_hub? It was started by somebody an year or two ago but seems to have been abandoned at a draft stage. I am thinking if everybody adds some information about extensions/pages they find particularly useful in the enterprise world, it will help future users but also help current enterprise wikis exchange experience. Does this seem worthwhile?
IMHO there are so much useful extensions that I think it can be a little much for that page.
For example if I edited that article I would put almost all extensions from our distribution there... so I'm documenting them on http://wiki.4intra.net/**Category:Mediawiki4Intranet_**extensionshttp://wiki.4intra.net/Category:Mediawiki4Intranet_extensions:-)
The question is, how much they are stable and secure. MediaWiki is
high-quality software that should not be impaired by low-quality extension. Also, when extension is unmaintained, it's stability and security becomes questional as well. Also, I remember for major MW extensions scalability is the big problem. Efficient SQL queries, using APC / Memcached cache, not invalidating parser cache too often. For example my own Extension:QPoll is not well-scaling requiring some major rewrites. That applies to many of another extensions as well. Dmitriy
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
There are so many extensions useful to the enterprise but probably also so many which are not useful at all or not maintained and if I wanted to start a corporate wiki right now I would probably be very lost what to look at and how people do things, so it seemed like a good idea to list the extensions that ARE actually used. Also, I guess one team solved a certain problem one way, while another solved it differenty, using a different extension or set of extensions, so writing this out might help everybody get new ideas/ avoid reinventing the wheel. But I guess I either asked on the wrong list or there is not much interest at all.
So, you're talking about some "basic set" of extensions that are thought to be definitely useful for ALL people?
It may be useful, but I think that it anyway may require testing of a complete distribution (MW version X + all these extensions) to recommend it to companies... And this returns us to the idea of a "pre-built" distribution like our one :-))
On Thu, Feb 7, 2013 at 1:31 PM, Daniel Barrett danb@vistaprint.com wrote:
...
- A desire for a department to have "their own space" on the wiki.
I assume you looked at enabling subpages in the main namespace?[1] That way Human Resources/Payroll/Show_me_the_money gets a nice breadcrumb up to Payroll and Human Resources landing pages. You can encourage people to create subpages rather than making yet another top-level page by putting [Create page] forms on landing pages that use a local template[2] and prepend the local hierarchy.
I'm not talking about access control, but (1) customized look & feel, and (2) ability to narrow searches to find articles only within that space.
(1) Code could infer subpage hierarchy and apply CSS from a corresponding CSS hierarchy.
(2) Add prefix: to the searches to search subpages, you can make a form for it[3]. Also Special:PrefixIndex can be helpful, e.g. just listing all subpages of the current landing page: == Subpages of {{FULLPAGENAME}}== {{Special:PrefixIndex/{{FULLPAGENAME}}/}}
Cheers,
[1] http://www.mediawiki.org/wiki/Manual:$wgNamespacesWithSubpages
[2] something like <inputbox> type=create preload=Template:Human Resources meeting buttonlabel=Create a new page for a Human Resources meeting default=Human Resources/Meetings/{{CURRENTYEAR}}-{{CURRENTMONTH}}-{{CURRENTDAY}} width=40 bgcolor=#f0f0ff </inputbox>
[3] http://en.wikipedia.org/wiki/Template:Search_box and similar.
-- =S Page software engineer on Editor Engagement Experiments
On 2013-02-12 12:55 AM, "S Page" spage@wikimedia.org wrote:
On Thu, Feb 7, 2013 at 1:31 PM, Daniel Barrett danb@vistaprint.com
wrote:
...
- A desire for a department to have "their own space" on the wiki.
I assume you looked at enabling subpages in the main namespace?[1] That way Human Resources/Payroll/Show_me_the_money gets a nice breadcrumb up to Payroll and Human Resources landing pages. You can encourage people to create subpages rather than making yet another top-level page by putting [Create page] forms on landing pages that use a local template[2] and prepend the local hierarchy.
I'm not talking about access control, but (1) customized look & feel,
and (2) ability to narrow searches to find articles only within that space.
(1) Code could infer subpage hierarchy and apply CSS from a corresponding CSS hierarchy.
(2) Add prefix: to the searches to search subpages, you can make a form for it[3].
It should be noted that that doesnt work out of the box but needs lucene/MWSearch extension.
For subpages to really fill this use case I think the page title would have to show only (or primarily emphasize) the subpage name instead of the full page name.
Also it sounds like in such a use case, one would want links to be relative to the current path first. If on page a/b/c you would want [[foo]] to link to a/b/foo if it exists and link to just foo if that page does not exist.
I think a good take away from this thread is that mediawiki has a lot of featuters that almost fit the bill but don't quite fully.
-bawolff
On 12/02/13 06:26, Brian Wolff wrote:
For subpages to really fill this use case I think the page title would have to show only (or primarily emphasize) the subpage name instead of the full page name.
I think it has been brought up in the past, there may be an extension doing that.
Also it sounds like in such a use case, one would want links to be relative to the current path first. If on page a/b/c you would want [[foo]] to link to a/b/foo if it exists and link to just foo if that page does not exist.
And where should the red-link send you to? That may be more confusing for some users.
We have ../ links, perhaps add also ./ ?
I wished for:
- A desire for a department to have "their own space" on the wiki.
S Page asked:
I assume you looked at enabling subpages in the main namespace?[1] That way Human Resources/Payroll/Show_me_the_money gets a nice breadcrumb up to Payroll and Human Resources landing pages.
Interesting idea, but I think subpages also bring penalties that are pretty significant. I discuss these in my book (http://shop.oreilly.com/product/9780596519681.do):
- Linking to subpages is quite cumbersome. The names get very long, and you wind up doing lots of [[foo/bar/blat/a/b/c | alt text]] links which add complexity to editing the page. We find that this discourages people from adding links to pages.
- When you enable subpages for a large community, they start using them instead of categories. In other words, users now have a choice between putting "Benefits" in the Human Resources category, or creating "Human Resources/Benefits." As a result, some Benefits pages end up in the Benefits category while others end up as subpages, making the "Benefits" category incomplete. An incomplete category can be worse than no category at all, because people look in it, don't find what they want, and assume it doesn't exist. Also, I'd rather have a category with 200 members than a page with 200 subpages.
- MediaWiki's UI does not indicate whether a page has subpages. There are extensions to solve this, but I haven't found one that integrates seamlessly into the user's daily experience the way (say) category links do.
For our large wiki, we decided that subpages in the main namespace are not worth these disadvantages.
Hope this was interesting, DanB
On 02/07/2013 08:17 AM, Mark A. Hershberger wrote:
(Added MW-Enterprise mailing list)
On 02/06/2013 10:00 PM, Tim Starling wrote:
For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.
Totally agreed.
I (along with a few other hardy volunteers) have been helping MW users at [[mw:Project:Support desk]] and it seems clear that the focus most developers have on the WMF use case has really made MW less usable for other people.
One of my clients had an older (1.11) MediaWiki installation that they are using to share information with their distributors world-wide. Their first attempt to get the system to do what they wanted was a flop since the Java developer they had working on the system really didn't know that much about MW. I was able to get the system upgraded to 1.19 and adapt MW to their infrastructure using hooks, ResourceLoader, and pages they could update in the "MediaWiki" namespace.
So, yes, I think MediaWiki has a lot to offer corporate users, but we haven't really made that clear or shown them how to do a lot of things they want to do.
Tim has it right when he says MediaWiki "needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over."
We've discussed this sort of thing over and over, but I think we're actually beginning to make some headway now thanks especially to work by Mariya Miteva.
I'm really happy to read this! Mireya is doing this work because Sumana, myself and other WMF employees thought it would be good to have an internship (funded by the WMF as well) dedicated to sort out the panorama of MediaWiki vendors.
https://www.mediawiki.org/wiki/Outreach_Program_for_Women
I have proposed the use of MediaWiki Groups as a tool for 3rd party developers, consultants, MW users etc to get organized. Creating a group officially recognized by the Wikimedia movement is easy, there is almost no overhead and it would increase your chances of pushing your agenda.
https://www.mediawiki.org/wiki/Groups
If someone doesn't feel like being inside Wikimedia then s/he can jump to these groups as a Trojan. From a tactical point of view it seems reasonable to think that using the Wikipedia / Wikimedia inertia for your own good is more efficient than trying to jump away or swim against. Many 3rd parties consider MediaWiki because it is used by Wikipedia. The Wikimedia movement at large can also understand that a healthier MediaWiki 3rd party community helps having healthier software for Wikimedia projects.
About the "nice-looking website aimed at this user base", what is mediawiki.org missing? And, more broadly, what is this community missing? Tim made very good points in the paragraph above. The next step is to define the tasks / projects needed and find the resources for each.
I'm happy helping in all these areas, but (needless to say) they must be driven by 3rd parties. Mariya will be working full time on "MediaWiki vendors" 7-8 weeks more. It would be great to use as much of her time and energies to build a minimum level of concretion and coordination. So far many of you have done a great job helping her to help you. :)
wikitech-l@lists.wikimedia.org