Thanks Paul,
I experience your contribution (below) as coming from a real straight shooter, concise, well thought out and thoughtfully presented, and based on your own experience. What more can I ask? Thank you very much. I find your insights informative and very useful, perfectly said and presentable to my boss when asking for money, "See, I'm not the only one needing support for a wiki in$tallation!" Thanks also for the recommendation of "Jim Wilson, can't recommend him enough!" I now know better where you're coming from, and I feel better informed to take what you have learned and shared, and adapt and adopt it to my own situation.
Me? I use Intuit Quicken for DOS from the 1980s (fits on one floppy). It's an incredibly sophisticated relational database. I see multiple bank accounts in the same database as I see multiple wikis on one MySQL. I see transfers between bank accounts as I see shared resources in groups of wikis. I see Quicken's multiple levels of categories and classes as extremely intelligent for sorting and selecting, making reports, and changing them globally on the fly as I see ... wait a minute, media wiki's categories aren't very powerful, and there are no classes. Quicken looks ahead of my typing for anything, and suggests matches, and offers to create anything new I type without having to exit from the immediate data entry task to reconfigure anything. MediaWiki allows quick page building the same way, but scant little else. In my Quicken, backup and restore, creating new databases and new accounts, and reconfiguring the whole program are simple, I even backup to an email attachment and save it on the web, program and all. MediaWiki has none of these features for the whole program, for just your data, or even just your custom configurations. Like open source programmers, the people who designed Quicken were paid nothing at the time (one difference, though, the paper stock Quicken-designers were paid with turned out to be worth $14,000 an hour when Intuit finally went public!).
My point is that 20 years ago, many of the things I expect in any modern, sophisticated software were already well worked out and well established. And I'm not even talking about Word Perfect or Lotus 1-2-3. I'm sad that the folk in today's open source community are trying to ride two horses at once - a day job for the rent, and a night job trying to help their open source baby (or hold the reigns on what should belong to everyone). Yet, they are not standing on the shoulders of those who came before them in the arena their customers are begging them to enter. Is MediaWiki the new FORTRAN, only for programmers and support staff, or is MediaWiki the new Netscape Navigator/ Communicator/Messenger/Composer, for everyone?
I guess it's 2 cents time. Thank you for yours. That's mine.
Anybody else? Where are you coming from and going to with your MediaWiki experience?
-- Peter Blaise
=== quotable ===
Paul wrote: ... I have read many of the messages on the list of the last few weeks and resisted jumping in until I saw whether you were going to find some untapped vein of knowledge or, more likely, you would need to do a lot of the legwork yourself with hints and near answers. I do find this mailing list VERY useful but typically not because I get the exact answer I need but more usually because it sends me off in the right direction to find it myself. This is fine with me and I have learnt a ton in the last 3+ months with help from some of the regular posters here. The lack of comprehensive documentation, setup instructions or the like whilst being somewhat frustrating is something that playing with MediaWiki you have to learn to accept, for now. I really don't know anyone that has the time to devote to building the type of documentation you are looking for BUT I do suspect that if sponsorship were available there would be candidates. ... sponsorship of an open source project from ... an organization would be interesting indeed. This isn't to say that people are only motivated solely by money but they have to pay their bills which personally I find absolutely fine. I myself needed some extensive changes made to the Mediawiki UI and after spending a few days looking I realized that Mediawiki is a complete beast when it comes to the construction of the UI and it's associated CSS. I took the admittedly easy way out and simply got an expert (Jim Wilson, can't recommend him enough!) to author a custom skin (www.scribas.com/archives which does everything we need. The site is currently in stealth mode and offline but you get a feel for what it will look like. The easier parts of Mediawiki, for me, have always been the data driven components. Data is data is data and so I have been able to change pretty much whatever I want by virtue of the fact that the data is stored in a known and well documented system, MySQL. Actually, on that note we are soon to be looking to migrate the index from MySQL to Lucene for fast cross-site searching/indexing of Mediawiki and Drupal. Anyway, the reason for my post. I could be way off track here but I suspect that a lot of the, admittedly logical, requests you have generated whilst being perfectly reasonable within the black box, vendor supported world are just a little ahead of their time in the Mediawiki/open source world. Be it Drupal, Wordpress, Joomla, Mediawiki, or whatever open source project I think you will always hear gripes about the documentation and feedback in the event of bug/problem. I don't think mediawiki is any worse or better in this regard and in fact having tested three other wikis I would say it is without doubt the most solid out there. So...the solution? I don't think there is one in the short term. As much as I would love to see comprehensive documentation I wont be holding my breath. Instead, I research, ask questions and generally make progress with help from this mailing list. Ideal? No, but you pays your money and takes your choice. I could have gone to socialtext and got a fully supported wiki but the cost would have been significant. Mediawiki is 'free' but comes with a sometimes costly lack of support framework. Oh, and the reason, in my humble opinion, for the fact that you see several names for the same entity is possibly quite simple. There are hundreds of contributors, each using slightly different phraseology. Regards, Paul
[more on Scribas visual design at http://webdesign.parkertorrence.com/zfrog/portfolio/scribas/ ]