Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Put MediaWiki to Work for You 171

Posted by ScuttleMonkey from the howtos-and-other-meme dept.
NewsForge (Also owned by VA) is running a short writeup on how to put MediaWiki to work for your organization. The writeup includes several addition tools that could be helpful in rounding out the overall package. From the article: " Imagine how useful it would be to have an online knowledge base that can easily be updated created by key people within your organization. That's the promise of a wiki -- a Web application that 'allows users to easily add, remove, or otherwise edit all content, very quickly and easily,' as Wikipedia, perhaps the best-known wiki, puts it. Why not bring the benefits of a wiki to your organization?"
This discussion has been archived. No new comments can be posted.

Put MediaWiki to Work for You More

Put MediaWiki to Work for You

Comments Filter:

  • Does it come with Admin tools? (Score:4, Funny)

    by blair1q ( 305137 ) on Sunday May 21, 2006 @02:46PM (#15376686) Journal
    Because I want to start a cadre of petit bureaucrats who think their subjectivity is objective and your objectivity is subjective.

  • Crap (Score:5, Insightful)

    by fm6 ( 162816 ) on Sunday May 21, 2006 @02:46PM (#15376693) Homepage Journal
    What a thoroughly useless article! It makes some vague assertions about what a MediaWiki good for, and than just regurgitates installation instructions. How about comparing this Wiki software with its many alternatives? Or even explaining why Wikis are so big?
    • Yup, you can almost heard it overdubbed in a soft-spoken male voice on top of muzak and footage of offices....

      as part of a sales pitch.

    • Re:Crap (Score:5, Insightful)

      by ClassMyAss ( 976281 ) on Sunday May 21, 2006 @03:23PM (#15376812) Homepage
      I'm not going to argue that for the majority of /. readers this article offers absolutely nothing they don't already know. But the fact is, once you leave the cozy confines of the IT world, your average business-person doesn't have a clue what a Wiki is or why anyone would use one. Since at least some businesses could probably gain quite a bit from this model of collaboration, I do applaud the intentions of the article, even if this isn't necessarily the correct audience to target.

      That said, your average business person stops reading the moment they get to "Next, find the LocalSettings.php file in your wiki directory. Add the following lines: $wgGroupPermissions['*']['createaccount'] = false;..." A better way to word this would have been "Now go find those tech guys you keep in the basement and tell them you want a Wiki."

      Just a thought.

      • Re:Crap (Score:2, Insightful)

        by ergo98 ( 9391 )
        I'm not going to argue that for the majority of /. readers this article offers absolutely nothing they don't already know. But the fact is, once you leave the cozy confines of the IT world, your average business-person doesn't have a clue what a Wiki is or why anyone would use one.

        The issue the other person seems to have isn't that this article exists, but rather that it was posted here (which you agreed to in the next paragraph). This is quite simply a bizarre article for Slashdot -- it's superficial, ther
    • explaining why Wikis are so big?

      From the article:

      let's see where the wiki comes into its own. Try editing the Main page, save the changes, and then click on the History tab. You'll see that MediaWiki tracks who made all changes and when. You can compare the differences between different versions. In one fell swoop you've got yourself a document management system as well as a potential in-house knowledge base.

      Let me put that into perspective. One of the main features selling M$ Word is easy to use vers

      • One of the main features selling M$ Word is easy to use versioning. So, imagine people at your place of work using a Wiki instead of emailing each other 20MB binary files and overwrite each others changes all day long.

        A collaborative editor might be a better replacement than a wiki. With a collaborative editor two or more people can have the same document open on different computers at the same time. When someone types words into the doucment they appear on other peoples screens in real time. With a wiki y
      • Let me put that into perspective. One of the main features selling M$ Word is easy to use versioning. So, imagine people at your place of work using a Wiki instead of emailing each other 20MB binary files and overwrite each others changes all day long. Give them a decent browser with spell checking and this is a much better way to share work. Oh yeah, it's also free.

        It's not both "much better" and "free." Either they have to give up some functionality, or they have to re-learn the wiki, and at the least yo
    • {{sofixit}}

      Wait...

    • Wiki works (Score:3, Insightful)

      by Rik van Riel ( 4968 )
      A wiki can be a great tool for sharing information in a company or another community.

      However, the information does need to be organized, otherwise you can only really put info into it and nobody will ever find it. Luckily Sinorca4moin provides a wiki editable navigation menu, that allows you to put some minimal organization on top of your wiki.

      This has allowed me to migrate the Kernelnewbies [kernelnewbies.org] site to a wiki. Now it gets regular updates again...

      • Re:Wiki works (Score:3, Insightful)

        by Chris Pimlott ( 16212 )
        I agree, you can't just open up a wiki and say "ok guys, go at it" and expect to get a reasonably organized site. You need someone - an individual or at most a small focused group - to create a baseline structure, a template to be followed. Over time the community can decide to modify them but there needs to at least be a precident to start from.
      • A while back I looked for an online collaborative book writing software and didn't find one. The closest I came was hieraki which is decent but not really what was looking for.

        For internal "corporate" documentation you need to be able to have projects, programs, systems, servers, etc all in a pretty deeply nested structure and each with it's own set of people responsible and with the ability to delegate permissions. Needless to say it needs to be universally searchable.

        Oh and one more thing, it needs to be

        • Re:Wiki works (Score:3, Informative)

          by Hewligan ( 202585 )

          ... but for some odd reason not one product written for zope/plone is nearly as good as products written in php/perl/ruby. Anybody know why that is?

          Because writing an entirely new content management system is actually easier than figuring out how to use the mess that is Zope/Plone.

    • Because they can't justify using it in an organization. It doesn't appear to have any kind of access control system whatsoever meaning that all users can read any of the items. In any decent knowledge management system you'd want to only allow certain knowledge to certain groups that need it, not everyone. Since this is contrary to what the Mediawikians believe philisophically you're best to move on and use another product instead of trying to shoe-horn this product into place in your business.
      • Why is this so? Where I work there is a constant push to share knowldege across the entire organization. The focus is on making sure everybody is aware of what everybody else is doing not only to avoid redundant workloads, but also to make the employees more rounded and to possibly foster joint and followon projects with the existing projects. In my opinion it's a great strength.

      • Re:Crap (Score:3, Informative)

        by hunterx11 ( 778171 )
        http://meta.wikimedia.org/wiki/Preventing_Access [wikimedia.org]

        You may personally dislike MediaWiki and Wikimedia, and that's fine, but it's no substitute for facts.

    • I agree. I saw the article title and was drafting an email to some of our managers to show why our Mediawiki setup was good and how it would help us.

      Then I read the article and decided it would be not a good idea to do that.

      Absolutely useless article, imo.
    • And the best bit is that MediaWiki isn't the best choice for much of anything. People use it because it's popular and because the installation instructions fit on half a page, but it's really one of the crappiest pieces of software you'll find. I've been through the source -- believe me. Or if you don't, at least consider yourself warned. You'll find some scary stuff, and you'll be amazed at how far the definition of the word "parser" can be stretched.

  • Because it involves learning a new skillset (Score:5, Insightful)

    by get quad ( 917331 ) on Sunday May 21, 2006 @02:47PM (#15376696)
    Learning how to successfully edit a wiki page can be quite easy, however learning to completely manage a wiki and learn all of its editing and layout syntax is another matter altogether.
    • Back in the day, we used these thingies called "text editors" to do all that stuff. But definitely, it's worth sending everybody in the company off to a two-week training course so's they can learn to format real purdy-like.

    • Is learning MediaWiki really any harder than learning Microsoft Office Word or OpenOffice.org Writer?

      • Probably not that much difference between mastering MediaWiki and mastering a modern word processor. MediaWiki might be easier as it has less features overall. But I think for a beginner, a word processor with a page of formatted text and friendly toolbars is a lot less intimidating than MediaWiki's sea of unformatted source code and basic toolbars.

        Someone needs to bolt one of these AJAX Web 2.0 Beta platform browser-hosted swishy word processors to the editing stage. :-)

        / On the subject of Office files bei
    • Well if there were any firefox extensions which would edit mediawiki using mediawiki formating, it would be a hell of a lot less intimidating for the average user.

      Managing a wiki isn't so hard, you just look at the RSS feed of changes on a daily basis and if there's a mistake, it's trivial to revert it.

      Cheers,
      Ben

  • I concur! (Score:4, Insightful)

    by Anonymous Coward on Sunday May 21, 2006 @02:50PM (#15376701)
    I work for a large visual effects company, and we have been using this resource for a while now. It is especially helpful when dealing with frequently changing pipelines and procedures, because it provides an easily modifiable up to date resource that can be accessed remotely from any machine on the lot.

  • Wiki (Score:3, Funny)

    by Wellington Grey ( 942717 ) on Sunday May 21, 2006 @02:51PM (#15376703) Homepage Journal
    The wiki solution to every problem: add more idiots.

    -Grey [wellingtongrey.net]

  • I can seen this now.. (Score:5, Funny)

    by goldaryn ( 834427 ) on Sunday May 21, 2006 @02:52PM (#15376706) Homepage
    Because of recent vandalism, or to stop banned editors from editing, editing of this page by new or unregistered employees is currently disabled. Please discuss changes on the talk page, or request unprotection. Anyone continuing to propogate stories about the CEO, the monkey and the baby oil will be severly reprimanded.
  • So... On one hand people are spending some more time in reading the injokes of their work-buddies but on the other hand, people are consumed by endless edit-wars.
    I can see how helpful it can be for a company.

    Seriously though, a friend of mine actually did install a wiki under the same premises of the article. They are having lots of fun with it, but it hardly helped their workplace.

  • I welcome Wikis to my organization (Score:2, Interesting)

    by Anonymous Coward
    I welcome Wikis to my organization. We've been using Dokuwiki for past year and it's been a success story. Knowledge is shared in an effective way.
    • We're in the same spot.
      We've grown from being ~20 employees about a year ago to being just shy of 50 now (not counting external consultants).
      We do spend face-to-face time on education, but the company wiki contains lots of information as well; and we really like the people who browse through it and ask questions regarding the material.
      It's definitely a timesaver.
  • I setup a wiki for our small software company a long long time ago. This really isnt anything new. Wiki's are great for documentation, especially with any rapidly changing products.

    Its cool that this idea is put out, but I don't understand why this is such a big deal. It was on newsforge, linked from ITMJ, slashdot too? Yippy?
    • It's so not new, it was the inspiration for the WWW (the first browser being a browser / editor, and the idea being somewhere to dump all that miscellaneous info about CERN that would also - unlike historical documentation - be easy to keep up do date).

  • worked for me (Score:5, Interesting)

    by bcrowell ( 177657 ) on Sunday May 21, 2006 @03:03PM (#15376747) Homepage
    It worked for me. I teach physics at a community college, and our physics stockroom has hundreds of pieces of equipment that we need to keep a catalog of. The solution we tried before was that the lab technician kept the catalog in an MS Excel spreadsheet. The problem with that was that if someone other than the lab tech wanted to add something to the catalog, or document the fact that they'd moved it, there was no easy way to do it. Also, the only way to get access to the latest version of the catalog was to ask the tech for the latest (paper or electronic) copy. None of this worked very well, for example, in night classes when she wasn't there. I converted the catalog to a wiki, and I think it's worked fairly well. Nobody in the department was familiar with the concept, so they needed a little hand-holding. But even people who aren't comfortable with editing a wiki can at least understand that there's this web address they need to go to in order to find a piece of equipment.
    • In a somewhat similiar situation - I hope in a few years inventory for 1-of-a-kind (not mass) items will become more automatic and economic to do all this via RFID tags when the readers become cheaper. I know my household would need it, just for the amount of books that go missing (have over 3K books and 2K magazines, many out of print) that are important for my wife's job in antiquities research.*

      *Yes, it would be easier to have it all stay in a designated library room, but then reality hits.
    • Sure, wikis are great. I use them myself. But this article does a sucky job of making a case for them.

  • Semantic MediaWiki (Score:3, Informative)

    by GerardM ( 535367 ) on Sunday May 21, 2006 @03:05PM (#15376750)
    When the public for a MediaWiki installation is not too big, a must have extra is the Semantic MediaWiki. It really helps in making content rich and when using it in an environment for more organisational knowledge sharing, it is one of the best extras you can find. Thanks, GerardM

  • Extensibility of MediaWiki (Score:4, Informative)

    by Anonymous Coward on Sunday May 21, 2006 @03:06PM (#15376761)
    MediaWiki may be fine, until you decide you want to extend it or maintain it. Take a look at the code! Spaghetti PHP mixed with spaghetti HTML mixed with spaghetti SQL, spread in an even layer everywhere throughout the system.

    Don't expect to be able to extend or modify it easily. I've come to the conclusion that it would be easier to reimplement it than to modify it.

    • Re:Extensibility of MediaWiki (Score:4, Insightful)

      by pchan- ( 118053 ) on Sunday May 21, 2006 @05:51PM (#15377268) Journal
      I managed to add a man page reader (ex: http;//kiwi/wiki/Man:fopen) into my company's wiki fairly easily. It was actually a bigger pain figuring out how to preserve the man page format than it was how to patch into MediaWiki and add an extension.
      However, you're correct. If you plan to change the look or behaviour of it, you are truly out of luck due to the MediaWiki codebase mess.
    • This story makes me glad that, at our company, we use OddMuse [oddmuse.org]. Yeah, it's got it's own set of warts and hacks, but it's fairly easy to understand, and extremely easy to modify and extend where necessarily.
  • We are using Mediawiki as documentation system to document all our servers, procedure and contacts within the tecnical departemnt. Since I am an open source advocate I introduced the system in 2003 and from there it only grew. Although you have to keep a look at it and do a re-structure from time-to-time to adjust to the amount of information it has been proven to be very useful. The only thing i am really missing is a good admin structure where it would be easy to configure a closed user group of editors
    • I agree that groups with various permissions would be useful. I use a wiki internally in a small business and would really like to invite people external to read/edit particular pages or sets of pages in the Wiki, without giving them access to the whole thing.
    • Do what we did. Have one wiki for general use documentation, and a 2nd wiki linked from the first with the sensitive data in, with read access to it locked down to those who need to know via AuthUser .htaccess or the like (I still don't keep passwords in it though, they stay in my master-password-encrypted store on my pda)

    • good password sharing solution

      WTF? Give them their own damn password.

      Man, security at your place of work must be really lax.
    • If you mean registration passwords, we made a custom register form where a user fills it in and a confirmation email is sent to all admins, it's their job to contact the person that filled in the form to make sure it's legit and click on the confirmation link in the email - no one but the person registering knows the password and they use the same form to change passwords.

      If you mean sharing servers passwords and what not, we store public PGP keys on the wiki and any passwords sent are sent by email encrypt

  • What's going on here...? (Score:4, Insightful)

    by WWWWolf ( 2428 ) <wwwwolf@iki.fi> on Sunday May 21, 2006 @03:13PM (#15376781) Homepage

    I'm not a MW guru, but does the article's idea of <PHP> tag really do what I think it does?

    As in "raw code in a a place where people can edit it?"

    Doesn't matter they are trying to limit the wiki's edit access only to registered users - this is wrong.

    Ugh. You know, one of the reasons why I like MediaWiki is that it does well with separating the page code from the HTML. And now these people want to sprinkle random PHP crap in the pages again. Argh.

    And as an additional bonus, you get to store your mysql_connect() parameters to the page source. Whee. Realllly smart.

    Somebody please submit this to TheDailyWTF...

    The real way to do this is to write a MediaWiki extension, of course (look at ParseFunctions for an example of something simple), which is then accessed through the usual hooks, like {{foo:...}}, but don't ask me, I don't know that much about MW's internal structure. I just know bad ideas when I see them. =)

    • The article states, "Install MediaWiki on a server that can be seen by everyone in your organization" and later "anyone on the network will be able to view the wiki". It's basically talking about Intranet access. Of course that's still horrible security thinking unless you're talking about a really small, trusted workgroup. You don't want anyone with some basic PHP knowledge to nuke your wiki without a trace.

      It uses the extension mechanism of parser hooks, it just uses it in the wrong place, Setup.php, w

    • The real way to do this is to write a MediaWiki extension, of course (look at ParseFunctions for an example of something simple), which is then accessed through the usual hooks, like {{foo:...}}, but don't ask me, I don't know that much about MW's internal structure. I just know bad ideas when I see them. =)

      The {{foo}} (variables) syntax is possible to extend, but does not, as far as I have been able to tell, support parameters. So {{foo:...}} won't work. See the UserNameMagic extension for how to add a Med

    • This sounded odd to me too, because I'd heard that limiting edit access to registered users was an available configuration option. So I checked: $wgGroupPermissions [mediawiki.org] does this now (1.5+), replacing $wgWhitelistEdit [mediawiki.org] (1.1+).

      This article offers the insane learning curve of giving a really broad overview of why you'd use a wiki, then discussing how to develop it. Typically, the builtin configuration pages or existing plugins would go in between those.

  • How to compare Wikis (Score:5, Informative)

    by wehe ( 135130 ) <<gro.libomxut> <ta> <ehew>> on Sunday May 21, 2006 @03:17PM (#15376798) Homepage Journal
    There are many different Wikis available. All with different pros and cons. To compare them all is the aim of the WikiMatrix [wikimatrix.org] project. If you are not sure which Wiki is best for you, WikiMatrix offers a Wiki choice wizard.
    • Wow, that's an awesome site. Thanks for the link. :)

      A couple months ago at my workplace, I proposed using a wiki in my group because we were having a lot of problems organizing our information and keeping it updated in a timely manner. My proposal was well received by the group and we went with Twiki , because it had already been setup by the IT department. Personally, I would not recommend twiki to anyone, because the syntax is horrible and the interface is very unintuitive (among a host of other downsi
    • Great link. I recently used WikiMatrix in a project to decide what wiki would work best (it has a good amount of information on each wiki and links of course if you need more details). My opinion on MediaWiki is that it is overkill for most applications that would have a small community. If you need scalability MediaWiki has it, but most don't need it and would be better suited with something else.
    • My god, thank you for that pointer! That wizard is fantastic at whittling down the data deluge.

  • Company wikis (Score:4, Interesting)

    by allenw ( 33234 ) on Sunday May 21, 2006 @03:24PM (#15376814) Homepage Journal
    Most of the experiences I've had with wikis inside our corporate environment have been mixed. A lof of folks (techie or otherwise) treat it more like a generic CMS rather than a hyperactive hyperlinking system. When they create a page, they make the assumption that it is their private page... so we end with page names like "Status". A lot of time is spent cleaning these up or the wiki becomes full of potholes.

    Sure, user education would help here, but there is only so much one can do... especially in a company of 30,000+ users.

    While wikis certainly lower the bar for producing web content, there really needs to be some sort of way to prevent users from doing things that they don't particularly realize are (overall) harmful. Or at least much better training tools.

  • Wikis are evil (Score:5, Interesting)

    by PietjeJantje ( 917584 ) on Sunday May 21, 2006 @03:27PM (#15376828)
    I like wikepedia, but I don't like wikis. Your "knowledge base" is your web site or documentation section. If you add a wiki, I have two places to search for information, do I have to look in the docs, or in the chaotic wiki, where you won't be able to find it anyay? Wikis seem an excuse for laziness, just throw the information somewhere instead of making a structured, well designed web site or documentation section.

    • Your "knowledge base" is your web site or documentation section.

      And your web site or documentation section is a copy of wiki page versions chosen by your program's release crew. Release engineers search for the version of your page that most closely matches the behavior of the release branch and then copy that version to the publicly viewable site that uses the same wiki engine.

    • It's a well known fact in large organisations that knowledge management is a bastard. All those people trying to figure out how best to share information, some of them trying out wikis, and it turns out all they have to do is design a website and maintain a documentation section! They're going to feel pretty foolish when they realise it was so simple!

      Seriously, get over yourself. There will be many cases where the employees of a company are capable of providing more content than those responsible for the w

    • Umm, make the wiki your documentation? After that it's well structured, easily searchable, and can easily be updated.

  • They work well when people want to share (Score:4, Interesting)

    by slamb ( 119285 ) * on Sunday May 21, 2006 @03:33PM (#15376842) Homepage
    My company has a successful MediaWiki installation, and I love it. All our technical teams (engineering, QA, system administration) are using it.

    I've put into it design documentation, instructions for accessing our other services (e.g. Subversion repositories), troubleshooting tips, sequence diagrams of various race conditions, you name it. I try to periodically dump everything in my notes directory into the wiki. The effort of cleaning it up means I'll understand it later, having it on the wiki server means it's backed up regularly, and as a bonus, other people see it and don't need to ask me as many questions, so I can spend more time developing. And it gives people a way to still get answers when I'm off bicycling through Africa.

    But collaboration technology like MediaWiki or bugzilla only works when people use it. There are always some people who won't play with others. If I put information on the wiki, they'll come bug me for it anyway. If I tell them it's on the wiki, they still won't read it. If I give them information verbally and specifically ask them to put it on the wiki, they won't do it. And then they wonder why I ignore their emails...

    • I've been pushing for years to get some form of wiki in our company. We develop a large application, but different teams don't keep up with what the others are doing. I wanted a way to extract information from peoples' heads into a usable form.

      Recently our IT people installed MediaWiki and I have been entering every bit of information I have to look up from other sources whilst trying to maintain a consistent structure.

      I've talked a few other people into using it, but takeup is very slow even though I can s
  • I actually installed MediaWiki last week as an attempt to get documentation moved off the dreadful pile of crap that is Lotus Notes. Its amazing how quickly useful content has been added to this since the documentation on Lotus Notes is updated so infrequently. The difference is that Lotus Notes is not very easy to use and MediWiki content is a simple search away.

  • Mixed results with our intranet wiki (Score:5, Interesting)

    by ewg ( 158266 ) on Sunday May 21, 2006 @04:14PM (#15376962)
    Our management wanted an "intranet" a few years back but had zero budget. My answer was JSPWiki [jspwiki.org] on a Linux box.

    The wiki has succeeded in a couple of notable areas. The photo directory page is critical for learning new faces on a rapidly growing staff. Another page has completely replaced sticky-notes that were formerly used to coordinate certain tasks among staff and interns. The IT department has a lot of miscellaneous documentation pages. A few other pages serve the function of an electronic bulletin board for staff scattered across two buildings.

    Management was very concerned at first that staff would abuse the wiki, either by wasting time posting trivia or by outright vandalism. Neither fear has materialized.

    The biggest failure of the wiki is the number of abandoned pages. They don't do any harm, but about a third of pages are derelict, with old information that the author obviously lost interest in maintaining. Having a wiki editor might solve that problem, but in practice it doesn't rise to the level.
  • I found Mediawiki pretty easy to set up. I used XAMPP http://www.apachefriends.org/en/xampp.html [apachefriends.org] for the Apache/MySQL/PHP layer as it's an internal project on our LAN so security wasn't a major concern.

    It's a huge improvement on any previous method we've used to organise our documentation - mostly FAQs, instructions, process documentation, links to external resources, screenshots, all sorts. Apart from backups (VBSCript to take a MYSQL dump and copy the images directory), I use HTTrack to take a 1 link de

  • Does it come with a wafer? (Score:3, Interesting)

    by The OPTiCIAN ( 8190 ) on Sunday May 21, 2006 @04:31PM (#15377029)
    I'm a wiki skeptic. It works fine on a large scale like wikipedia, but smalls-scale wikis - such as in your office - tend to be rubbish. Nobody has ownership over content and they suffer from the tragedy of the commons. I think it's probably more effective to use a blog for lots of internal communication, and then probably some sort of CMS-with-comments where you need a graph of pages.
    • Content ownership on a wiki is no different than code ownership in a typical source control system like CVS or Subversion. If you want team members to 'own' specific parts of the code or documentation, it's up to you to make the assignments and ensure that people do their work.

  • Did that at my company... (Score:3, Interesting)

    by NeutronCowboy ( 896098 ) on Sunday May 21, 2006 @04:50PM (#15377100)
    ... and I consider it one of the best things I've done there.

    The situation we used to work in was that we had a lot of customer information that changed quickly, a group of engineers who worked disparate hours (there was supposed to be someone available between 7AM and Midnight) and documentation that was scattered all over. We had a central repository for documentation, but it was the pits. You could only search on key words or categories, check-out and check-in procedures were laborious, if not counter-productive, and everything had to go through an approval cycle. Finally (and that, combined with the fact the repository was unsearchable, was kinda the nail in its coffin), reviews were partially based on how many entries you'd submit. The end result was an essentially unsearchable repository was filled to the bring with duplicate entries and outdated stuff.

    Fed up with that, we created a Wiki on the side project. Initially I filled it myself with random things that I found useful. Then other people started using it. It wasn't perfect, but it was loads better than what we had - we could actually find information! Outdated stuff could be updated. People didn't have to call others at all hours of the night for server information anymore. And best of all, new hires could be pointed to it, and they could find useful starting information.

    To give you an idea of how successful it was, it was initially completely disallowed by management, as it was creating a duplicate information store. The desktop server on which it was stored was yanked. But it stuck around, because people actually used it. Now, the entire group uses it for storing training, server, contact or any other information that a lot of people need and that changes often. Contrary to the commercial data storage software, it helps us do our job more efficiently.

    Wikis are undeniably useful and loads better than anything else out there - if you make sure that the information you try to make accessible falls in the following categories:
    - lots of different people can use it
    - changes often
    - lots of people can contribute to it

    Oh, and it also helps if people aren't dicks, to use Wikipedia's rule.
  • Comment removed based on user account deletion
  • At our university we have several different instructors teaching a series of logic courses. Currently, each instructor uses their own favorite notes and textbooks. This means that what students learn in in one class is different from what is used in the very next course in the series. We also have several different instructors for the same course, each develops her own course materials. It's a mess.

    We have started using a wiki to cooperatively develop materials for this course. We hope that it will ev
  • We've used the Wiki for a while now at ECONZ http://econz.com/ [econz.com] and it has been very useful. All it needs is someone to take control of the formatting of the site, rather than just leaving everything totally free range. The one remaining problem is the actual editing process, which MS Word users can't seem to get their heads around.

    We did find FCKEditor http://www.fckeditor.net/ [fckeditor.net] but that doesn't come built-in and support is beta. Mention that to the system admins, and they'll refuse to install it. Once that
  • I believe Lifehacker had an article showing you how to set up a MediaWiki on a Windows machine [lifehacker.com].
    I tried this, and it worked quite well.

  • Which Wiki? (Score:2, Interesting)

    by dugjohnson ( 920519 )
    I finally (last week) got a go ahead on a Wiki which I have been playing with, but couldn't get anyone else on the sub-group to play (on the road, not enough time, yada yada) to at least stick one on the new intranet. I was working with MediaWiki, but their install readme says it is more for Unix/Linux and this is a strictly Windows house. I think it oughta work on the Windows server, but haven't set it up there, and wondered if there is any recommendations amongst the /.ers of a Wiki that will be easy to

    • To start hacking on the awesome Semantic MediaWiki extensions [ontoworld.org], I downloaded XAMPPLITE (MySQL, PHP, Apache, and phpMyAdmin all nicely bundled for Windows) and the MediaWiki source. I had it up and running on Windows XP in 10 minutes!

      For PHP development, I downloaded Eclipse and the PHPEclipse extension. I already had Cygwin and Vim installed, but I don't think you need them.

      I've also used TWiki at work. The benefit of MediaWiki is the users' familiarity with Wikipedia.

      Semantic MediaWiki adds attribut

  • We're using an in-house MediaWiki knowledge-base system here. It's been running for over a year and is a huge step forward from the previous setup we had(which was developed in-house in CF). The hardest part was writing code to export/parse/import from the old system to MediaWiki. Once that was done it's been smooth sailing

    Some useful add-ons we've used are:
    http://bugzilla.wikimedia.org/show_bug.cgi?id=1924 [wikimedia.org] (a patch to have restrictions of namespaces to certain groups)
    http://bugzilla.wikimedia.org/show_bug [wikimedia.org]

  • MediaWiki seems a strange choice for corporate use (Score:4, Insightful)

    by soliptic ( 665417 ) on Sunday May 21, 2006 @06:58PM (#15377446) Journal
    I'm involved in the team implementing a new intranet (or extranet I suppose, it's international) for my organisation. A few months ago I wrote quite a lengthy paper extolling the virtues of Wiki and it's possible applications in the corporate world, for which I did a little research into MediaWiki and it's many alternatives (see also: the WikiMatrix link posted above).

    Now, I may be wrong, (and I welcome corrections if so), but from what I gathered, MediaWiki has poor-to-nonexistent support for advanced granularity of permissions. Essentially, everything is editable by everyone. Beyond that, there is a very simple level of control inasmuch as admins can lock a page and whatnot. But setting up a system whereby users come out of AD/LDAP and can edit (or not) different areas corresponding to their department/group, or setting up workflow systems where (for example) anyone can edit but it must be approved by a departmental admin (who can act as admin within their department's pages, but not elsewhere) before showing up... It didn't look as if any of this was possible.

    Furthermore, I was told there's no point even asking for it. Because such things don't gel with the Wikipedia philosophy, the people spending their time coding MediaWiki simply aren't interested in implementing them. (Don't get me wrong, I'm not whinging about this - naturally they should devote their time to features which actually suit their demands, not somebody else's).

    So it seems to me very odd to promote MediaWiki for the corporation, when other systems have much more sophisticated ACL-type features, granular permissions, and so on.

    Comments welcome?

    (PS. FWIW, we eventually settled on Plone. Plone does have a Wiki plugin so if we ever do use Wiki's I guess we'll use that. But I'm still evaluating which Wiki system to use for a separate project, outside work, but which still requires more advanced editing permission granularity. DokuWiki seemed the best fit, with the one problem that it uses flat files for storage, and our sysamin would prefer a db backend as they have a dedicated db box, so it'd be quicker. WikiMatrix narrowed it down to ErfurtWiki, Midgard Wiki, miniWiki, PhpWiki, TikiWiki, WackoWiki and Wiclear: out of these, I didn't like the look of phpWiki for some reason I can't remember right now, and I've never even heard of the others. If anyone has any experience with any of these systems, please do share :) )

    • Fine-grained permissions don't gel with wikis in general, not just mediawiki. The idea behind a wiki is that most people are well-intentioned (this is triply true when they're using company resources), and that it's good to have lots of people collaborate. Even if readers aren't directly related with your project, if someone is interested enough to read the content, they might briefly stop to contribute in a number of different ways (some people will wander by and fix spelling mistakes... other people mi
      • The idea behind a wiki is that most people are well-intentioned (this is triply true when they're using company resources), and that it's good to have lots of people collaborate. Even if readers aren't directly related with your project, if someone is interested enough to read the content, they might briefly stop to contribute in a number of different ways (some people will wander by and fix spelling mistakes...

        Very true, point taken.

        In fact I did make that point in my doc. Something along the lines "al

    • But setting up a system whereby users come out of AD/LDAP and can edit (or not) different areas corresponding to their department/group,

      For this reason, we used the Perspective Wiki -- IIS based, uses integrated AD authentication. Probably not the greatest Wiki software, but in my opinion any system that requires another password is a system that people aren't going to want to use.

  • Wikis in Enterprises (Score:2, Informative)

    by avatar-99 ( 640119 )
    You can find information and a survey (in German!) about Wikis in Enterprises here: http://wikipedistik.de/umfrage/ [wikipedistik.de]

    Hopefully this information will be translated to english in the next 1-3 days.
  • As I told newsforge a few months back, we have seen unparalleled success with deploying MediaWiki at our company [backcountry.com] as an intranet. What started 13 months ago as a quick way to get an intranet up and running has now blossomed into a vibrat communications channel with over 7000 pages, all written by our employees. It has become the defacto home for development specs, engineering and network documentation, vendor notes, product notes, warehouse processes, call center training, etc. Some things I've learned:
  • I realize that mediawiki is the current myspace of wikis, but it is not really ment to be deployed in a corporate environment. Most corporations would need to use a wiki with more access controls like TWiki or confluence.

    I've heard that a while ago, some folks inside Intel set up a mediawiki site for internal documentation, and when the lawyers heard about it, they had the project shut down. There was too much liability I gather.

    Anyway, I've set up a TWiki installation at my work three years ago now and a
  • The problem with Wikis is the lack of a standardized markup language. They all differ in subtle ways. This is fine if you only use one, but I use several.

    Hopefully GUI editors will minimize this problem.
  • I futzed with a few wikis to try and orgnise all the disparate parts of my life (which were usually recorded on a swarm of post-it notes). My main problems were having to setup/admin a httpd server on which to run the wiki, and then backing up/restoring the information in the wiki.

    Eventually I found tiddlywiki [tiddlywiki.com].
    Pros:
    * no httpd required
    * all information stored in a single html file (including the wiki code itself!)
    * has tags and a search function
    * monstrously quick and easy to set up.

    Cons:
    * haven't found any
  • Submitter has a bad case of Wikiphilia [hacknot.info].

    I wonder if it's related to Morgellons [morgellons.org]?

  • Imagine how useful it would be to have an online knowledge base that can easily be updated created by key people within your organization.

    Probably written by someone who hasn't thought about it or tried it. In my experience Wiki's have the same fault of most other "management" software. Unless people must use it, it's a waste of time.

    It's not typically the software's fault, it's the people. Managers are lazy/busy and resistant to change. Frankly most of them don't have the skill to organize a wiki

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close