Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
We're thinking of moving from our existing installation of MediaWiki to something more feature-rich. I'm trying to find all the pains people have with MediaWiki today (mainly it's poor handling of external documents and less-than-perfect editing capabilities - compared to Word).
We are using a wiki for design, spec, process guidelines. We have several external documents (docs, powerpoints) that we are currently putting on a shared folder and linking to from the wiki (because uploading files is not very convenient in MediaWiki).
We are trying to make the friction minimum, so that nobody will have an excuse or reason for not using it.
Some options we're considering are Confluence, Trac & Sharepoint. Money is not a big concern, only ease of use (and maintenance) and feature-fullness. What would you use?
I would plug the details of my specific feature needs into the excellent WikiMatrix choice wizard and let it make recommendations.
I would advise either
Foswiki ( http://foswiki.org ), (forked by the whole developer community of TWiki to avoid trademark threats), for a feature-rich and fully open programmer's wiki. Drop on #foswiki on irc.freenode.net to chat with the community.
Mindtouch's Deki Wiki ( http://www.mindtouch.com/ ) clearly the most user-friendly advanced and innovative wiki out there, a modern commercial + open source offering. Great integration with Office docs.
I would avoid Confluence. Confluence made a design choice (forbidding mixing html in pages with Wiki syntax) that proves deadly to any attempt at wysiwyg, as it uses a standard HTML editor for WYSIWYG, and this converts it on save in a very limited subset of it, yielding frustrating surprises for the users (foswiki for instance keeps as html the parts the wiki syntax do not handle like bullet lists in table cells). Confluence have many great sides, notably its integration with atlassian great tools as their JIRA bugtracker, (we use it at work for this with good results) but do not plan to customize it.
There are many good choices on hosted wikis too (Google sites, based on the awesome jotspot engine is one).
Never use Sharepoint of course. Its wiki capabilities are a IE-only joke, and Sharepoint whole architecture is braindead (storing all data - even huge docs - in a non-distributed database goes against Microsoft own recommendations). If you want a DMS with good Office integration, have a look at KT (Knowledge Tree) instead. http://www.knowledgetree.com/ . For political reasons we were forced to use Sharepoint at work but we limited it to basic document managing (never use the MOSS higher layer, as it breaks compatibility between versions) and integrated a foswiki frontend to it (dumped document list & metadata in xml and provided navigation in foswiki, and search with a google box)
But my real advice would be to ... wait for Google wave, that promises to revolutionize the wiki concepts.
Disclaimer: I am part of the foswiki community.
Before you move away from Mediawiki I would urge you to consider the many extensions available. IMO there arent many wikis that offer more features that MW, especially when you consider the number of extensions. See http://www.mediawiki.org/wiki/Category:Extensions
For example, for editing there are browser based editors similar to Word. And there even macros for Word that allow you to export from MS Word to your Wiki, from within Word.
Also, check out the Semantic Mediawiki extensions. These give enormousness benefits in the area of Knowledge Management.
I would personally recommend against moving from Wiki to SharePoint. The huge problem there is SP's dreadful handling of images.
First of all I would stay away from Sharepoint. Period.
I would not consider switching to Trac either, since Trac has special focus on issue tracking, and poor support for external documents.
I would consider switching to Confluence, since:
Money is not an issue (as you said)
You want to minimise maintanance work (as you said)
You want to use wiki to handle external documents (as you said)
I'm typically a strong advocate of open source technology, but with the requirements you gave, I just don't think they would make you happy. For instance if you had personnel available for maintaining and providing customisations to your system, I would definitely suggest trying out Foswiki, which also would otherwise fit your needs very nicely. However, if you really want to stay away from any extra maintance work, Foswiki is not a good option.
I work on Tiki Wiki CMS Groupware and I'll share a few links. This question comes up quite a bit so we have a dedicated page: http://tiki.org/Tiki+vs+MediaWiki
We're thinking of moving from our existing installation of MediaWiki
Tiki & MediaWiki are both PHP/MySQL so you can use the same server.
Tiki has a built-in importer: http://doc.tiki.org/MediaWiki+importer
to something more feature-rich.
Tiki is the http://tiki.org/FOSS+Web+Application+with+the+most+built-in+features
We are using a wiki for design, spec, process guidelines. We have several external documents (docs, powerpoints) that we are currently putting on a shared folder and linking to from the wiki (because uploading files is not very convenient in MediaWiki). We are trying to make the friction minimum, so that nobody will have an excuse or reason for not using it.
http://doc.tiki.org/WYSIWYG
http://doc.tiki.org/File+Gallery (instead of your shared folder)
http://doc.tiki.org/Docs (web-based ODFs)
http://doc.tiki.org/Spreadsheet (web-based)
http://doc.tiki.org/Slideshow (web-based)
http://doc.tiki.org/Draw (web-based)
Some options we're considering are Confluence, Trac & Sharepoint. Money is not a big concern, only ease of use (and maintenance) and feature-fullness. What would you use?
Tiki is Free/Open Source. But if you have money burning your pockets :-)
http://tiki.org/Donation
You can also hire a consultant to provide training/support and to accelerate the implementation and/or sponsor feature development
http://info.tiki.org/Consultants
Have you considered sharing your Word documents with Google Docs? It has revision control and collaboration features like a wiki, as well as a rich text editor that can import and export plenty of formats.
It sounds like TWiki would be a great option for you as well. I haven't used it myself, but it also has a rich text editor, as well as tons of enterprisey project management features in it.
A lot of people seem to like Confluence. I personally don't know it. If you are not already at it and you want something feature-rich than xwiki could be something for you.
I'd add FCK Editor for WYSIWYG, get a decent document management system to run alongside the wiki and carry on with MediaWiki!
Related
Currently our team is using MoinMoin as a wiki for IT and it's so nice.
We want to promote to use wiki for end-users because some of them are interested. On the wiki we'll share and edit requirements of aplications, for instance.
I think MoinMoin is not the more user-friendy (but I love to use it) that's why we are looking for the best user-friendly wiki for end-users/customers
For yourself MoinMoin is obviously user friendly. =) Seriously, consider all users and try to figure what kinds of usage patterns you have. MoinMoin is a reasonable choice since it's such a simple program. You can often help your non-programmer users by adding a feature or two to MoinMoin. Developers are up to speed with it and you have all the content there already.
That said. Mediawiki is used for lots of general wikis out there today. Including Wikipedia. An aspect of user friendliness is recognition. Mediawiki might feel more friendly because users are more familiar with how it works. And Mediawiki is widely adapted. Lots of extra features you might want to add to help your users are already written as extensions. And Mediawiki's extensions API is really good so you can easily automate your own verticals when the need arises. Mediawiki is reasonably feature rich without being totalluy overloaded. It has categories and templates which both come in handy for keeping things DRY and using the wiki in various processes. It shares lots of its syntax with MoinMoin since both have the same ancestor (syntax-wise).
I'd probably go with Mediawiki.
Visit Wikimatrix.org to determine what features you need and what tool is best for you. I often mention Foswiki.org as a very nice and userfriendly tool, but it really depends on the features that you need.
I have yet to see any Wiki that is more end-user friendly than Confluence.
Just the most important reasons:
While other Wikis say they have WYSIWYG editors, what they actually do is enclose selected text with markup when clicking an icon. That is not WYSIWYG, that's code injection! In Confluence 5 all editing is done from a visual editor (you actually DO see what you get right away straight within the editor). With the ability to add macros (markup) by powerusers.
In almost all other wikis the users are entirely responsible for creating and maintaining the link hierarchy. This means broken links and orphaned pages will be the norm. In Confluence all pages are automatically added to a page hierarchy and sorted by name. You can enable the tree browser via the Documentation theme to make browsing the wiki even without manually added links convenient. Lastly you have the ability to reorder pages in any order via drag & drop.
However, Confluence is rather costly for > 10 users. But well worth it if you can afford it, or you don't need more than 10 editors. Pure "readers" do not count towards users if anonymous viewing is enabled.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What features should "Tomorrow's" wikis include? How might they incorporate Web 2.0 features like AJAX? What other features are they currently missing? What do you want to see from the next release of your favorite Wiki?
Edit: How might a Wiki be integrated into other products? What "neat uses" could wikis have?
Preview-as-you-type works very nicely indeed here on Stack Overflow. Many wikis don't do that.
Make it really easy to link between pages, eg. that, as you type, the wiki finds likely pages you may be referring to. That way you can make links without having to know the exact title of a target page, and bouncing on the shift key to WriteInCamelCase, or throwing in square brackets. Make it very easy to link to other websites outside the wiki, too (and by "easy" I do not mean like wikisisters, which, if I remember correctly, is like foowiki:ALinkLikeThis).
Similarly, if you can generate links within text automatically, you could, for example, have a mail system that wikifies your email. You create a wiki page, say, for Joel Spolsky, and references to Joel emails in your inbox become links to that page, which you can find by clicking "what links here". (This probably needs something along the lines of Bayesian filtering to prune the stray references to other Joels... your Bayesian Classifier learns that if the context is smart and getting things done, it's Spolsky. If it's flying Viking kittens, it's morely likely Joel Veich).
A variety of RSS feeds for tracking changes would nice, too. (Diffs, full text, changes on pages I've edited, ...)
Wikipedia has grown a fairly colossal categorisation system ("Fictional Cats", anyone?); laying a taxonomy over a wiki's flat namespace could provide another way for users to find their way around. Wikipedia's doing this a little, but in fairly limited ways so far: there are links to the relevant category lists, but you can't, for example, look for a composer called "Smith".
Similarly, wikis give you this big graph of interconnected nodes, of how closely your community sees the relevant concepts as being. Is that interesting? Is that useful? Does anyone who isn't google want to think about this stuff?
PS. If you believe Paul Graham's definition of Web 2.0 as "Democracy, Don't Maltreat Users, and Javascript works now", wikis are two thirds Web 2.0 already.
I am personally already tired of wikis. Wiki as a software is outdated, now it is about wiki as a feature (like my favorite new website, stack overflow).
The main advantage of community wiki — more editing — came into existence when we introduced "Suggested Edits".
With "Suggested Edits", anyone, even an anonymous user, can edit anything — so long as another experienced user reviews and approves their edit.
I'm in the process of choosing a wiki tool, and have looked at numerous packages over the past week. I'm sure there are dozens I haven't even heard of yet, probably good ones. But in general, here's my "beginner's mind" take on the problem.
Wiki markup should be abandoned. A wiki that is limited to wiki markup will only be useful to 'nix hacks and others who get excited about doing things the hard way and insisting that everybody else is stupid. I mean, Morse code is fine with me personally; I don't get what was wrong with a nice, clean dash-dot-dash. Or smoke signals, they were nice, except for the carbon footprint. But times change, and we have to change with them.
Real users (business users, customers, clients) want rich text editing. Period. And when a wiki tries to support both rich text and wiki markup, the results are not pretty. The model is confusing and (apparently) difficult to implement. The fckeditor extension at wikiwiki is a nightmare, for example. It's just not worth it.
Wikis need better access control. The idea that all content should be open to everyone is fine for an open, public, non-profit wiki like this one. But in the business world, that's not how it works. Restricting access is not evil, it's reality. Wiki tools need to do a much better job of providing access control: access to pages and groups of pages based on role or group membership, where groups can be formed by anyone on an ad hoc basis and users can belong to multiple groups and pages can be accessible to multiple groups, at the whim of the page's creator.
Those are the two things that I want, above all else, and I haven't found it in open source, at least not out of the box. Which, of course, is why open source is open source.
There's been some interesting work using wikis for testing and software development. EG, movement towards literate programming -- allowing pages to exist as both code and documentation that is compiled down into one or the other (or, I suppose, both simultaneously).
They have a regular session about this at the annual WikiSym conference.
I think one direction of Wikis is going from open ended collections of documents to an "everyone can edit but with more structure" applications like SO.
Another direction that I've seen is more direct integration with other project support tools, so project planning, issue management, and all that stuff.
Personally, I think the next big direction is going to be some sort of multimedia based Wiki, not just a Wiki where multimedia can be embedded in the text.
I really like MediaWiki. It's widely used and free/Free. The markup syntax is straightforward and allows you to do enough basic styling that you don't need to use custom HTML or to use a WYSIWYG. I assume by "sexy web 2.0" you mean Flash/AJAX, but I like MediaWiki because it works cleanly with basic HTML/Javascript (you don't have to wait for custom widgets to load, etc...).
What makes wikis reach their potential of usefulness is the community that develops around them more than the software itself. You need to find a niche where people are both passionate about (but not criminally insane about) the central topic and have enough technical prowess to log on to a website and edit some text.
"Wiki" is ultimately just a pattern:
Open editing by all/most visitors
Integrated revision tracking and rollback to reduce the cost of mistakes
Simple syntax for cross-linking between articles, and auto-creation of stub articles when referenced
That's not a perfect description, but it's a combination that isn't particularly magic. Successful wikis combine those things with a critical mass of people creating and maintaining content.
The next step, IMO, is less about web 2.0 shininess and more about the integration of better structural information. Adding any metadata beyond "this points to that" is an exercise in brute force hand-markup. Maybe microformats? Maybe the development of more structured knowledgebase software that uses wiki-ish editing UI but a smarter backend? I'm not sure, but I think better handling of the structured data is really the next wave.
Extensibility.
Check out DekiWiki, they are doing an excellent job with this.
DekiWiki extensions
The wiki-of-the-future will be completely editable online, concurrently by everyone. Check out EtherPad for a demo of the techonology.
For me, in terms of Enterprise style uses for a wiki, I have a couple of thoughts;
An effective way to keep and synchronise a central, web based wiki with multiple, offline, desktop style wiki's for people on the go
To move towards wiki as a function as opposed to wiki as a system, so we can integrate the wiki collaborative system into other things
Do you use a wiki in your company? Who uses it and what for. Do you share information between projects / teams / departments or not?
We use ours to store
Coding Style docs
Setup and Deployment procedures for web servers and sites
Network diagrams (what are all the servers in Dev, Staging, QA and Production called etc.)
Project docs (pdfs, visios, excel, docs, etc.) are stored in SVN. For the non-techies we have links to those docs in the wiki that point to an up-to-date share on my box. (tip: some wikis provide source control integration but ours doesn't)
Installation and Setup procedures for development tools
Howto's on things like using our bug tracking system, our unit testing philosophy
When doing research on a topic I often capture the important information in a wiki page for others to learn from
I've seen them used to keep seating charts in medium to large size organizations for the new people
At my previous company all of the emergency contacts and procedures for handling a critical outage where available on the front page of the wiki
The best part about a wiki is that it's searchable. Some wiki's support searching inside uploaded or linked docs as well.
If you setup a wiki and encourage or even require people to use it the amount of information that will accumulate can be amazing. It's definately worth the effort especially if you have someone in IT with some spare time on their hands to set it up.
Do you use a wiki in your company?
= We use it for the purpose of a Knowlede Based. Basically it is a wiki but many more functionalities intagrated.
Who uses it and what for
= Employees. Knowledge Sharing, Preparation of collaborative-documents, etc.
Do you share information between projects / teams / departments or not?
= Depends on the requirements. It is possible to set permissions between users.
We use a wiki, for documenting our systems. It's updated gradually as things update and evolve. It should go without saying that there's benefit in that, however whether you use a wiki or other methods is worth thinking about.
A wiki is great for collarborative editing. The information shouldn't go stale in theory, because as people use the systems they have the opportunity to keep it up to date.
However we have found in our organisation that people struggle a little with wiki markup. Especially tables. I think a solution that has wysiwyg editing would be better if you have non-highly-technical people editing it. Sharepoint springs to mind, but it's expensive.
I use a wiki as my virtual "story wall" for agile development. All of my stories are written and organized in the wiki. While my customers are reasonably local (we can have face-to-face meetings), they aren't co-located. To enable better customer interaction I've resorted to a wiki instead of a wall-based story tracking mechanism. It also works a little better for me due to the fact that I often have multiple, concurrent projects and limited wall space in my cube. In a larger team with more focused projects and more wall area, I'm not sure I'd make the same choice.
My company uses a wiki for project-planing but also for storing documentation and ideas.
I have found that a wiki is a great way to link the programmers in the company with the business-people.
When someone who are not on the programming-team comes up with an idea or finds a bug, it's a loot simpler to let that person document it in the wiki.
I think it's an important aspect for a small company like mine to easily synchronize the business-team with the development-team. A wiki helps with that, since it gives the feeling of being a part of the development process, instead of having to ask the programmer directly about every little detail.
we have MediaWiki to store technical information that is not ready to be published in other formats - specification drafts, diagrams (via GraphViz extension), results of short investigations, etc.
I also think this question is a wiki too :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When designing a wiki application, what things should I take into consideration?
So far I have:
revisions
parsing some sort of markup text
keeping track of links in wikis, and pages that link to other pages.
related wikis i.e. wikis are related to others.
What else goes into building a Wiki?
If it's helpful, here is the database schema for Wikipedia (actually MediaWiki, the engine behind Wikipedia):
http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png?
I have done a lot of research and work with wikis over the last several years, for my own use and to support technical teams for my various clients/employers.
I have concluded that the most important criteria for a wiki is to make it transparent, like the original wiki at http://c2.com/. It should be so easy to contribute that the user never questions whether they should bother to do so. The editor must be easily accessible, it should use a conventional text-only (NO WYSIWYG!!!) wiki format, it should be easy to add new pages, it should be easy to link to external pages (other wiki or regular web), and it should have backlinks. Imitate the original wiki, and you will be fine.
If a user ever questions whether they should bother to contribute because it is too painful, in one way or another, then the wiki will stall and fail. I have seen it happen over and over again. WYSIWYG is one common failure mode, mixing in "rich" content like lots of files, multimedia, etc., is another, not being able to backup/restore is a big one. If you want "fancy" content, use a standard web server hosted "nearby", to which wiki users can link. Remember, wiki is about communication, it is NOT about pretty.
Have a look at TiddlyWiki. I think it has the best combination of features I've seen in any wiki. (For "pages" below, read "items" since TiddlyWiki is a single-page wiki. But I think these features should apply to wikis with pages too):
List of all "missing" pages (WikiWords with no page)
List of orphaned pages (pages with no links to them)
Most formatting is done by editing wiki pages
You can't screw up formatting, because there's a default if you delete your custom formatting
You can tag pages
You can include a page in another page
And plenty more that I haven't mentioned. I think the formatting is possibly the best of many good features, because it's so easy to edit and so hard to screw up.
Often overlooked:
Good search
Hierarchies. One of the things I miss most in Redmine's wiki.
If you find a good way to implement a wiki that is easy to reorganize, that would also be great (i.e. rename a page, or join two pages into one and don't break a zillion wiki links).
User interface -- one of the most frustrating things for users is that they have to learn one user interface for MediaWiki, one for TikiWiki, and one for any of the other myriad of wiki's out there.
The most important part of wikis is not the technical feasibility -- it's getting users to contribute and edit in a convenient and effective way. You can have the most technically robust wiki in the world, but if it's not easy to use, it will be useless as the community tool that a wiki is supposed to be.
Either copy an existing and familiar wiki syntax (such as MediaWiki), or be prepared to invest heavily in creating a WYSIWYG editor.
I wouldn't start a new wiki engine with the same features that everybody has, there are so many of them out there.
I would only work on one that offers something different/unique, much more than a standard wiki.
Some ideas include (maybe some wikis already have this):
The ability to have the wiki merged with a VCS, to discuss revisions/changes and be able to do code reviews (anything that gets committed automatically creates a page for the revision), having it linked to the committer and anybody in the discussion and sending them email alerts would be nice.
An API for the wiki that allows 3rd party application to do mashup-style integration.
wiki-style multimedia (Text, Images, Audio, and Video) that contains links to other media.
multilingual side-by side editing and translation.
a client-side editor/viewer (not web based) for faster response and real WYSIWYG editing.
...
Make sure you nail Ward Cunningham's original Wiki Design Principles.
Make sure you perform input validation on all the edits people make to prevent XSS. Nothing would ruin a good wiki like people getting hacked.
Every time I've tried to get non-developers to use a wiki, the difficulty of writing text has been the biggest barrier. A WYSIWYG editor along the lines of what StackOverflow has seems like a great idea to me. It still shows the markup in the box, so motivated users will eventually learn to use it (thus becoming more efficient), but it also shows a live preview, so that users get instant feedback as to whether their text looks correct.
Along these same lines, another annoyance is that every wiki seems to use slightly different markup. I guess each designer thinks they can do it better than the ones before. I would suggest using either MediaWiki's syntax, or something like MarkDown that's sort of standard, so that power users will have an easier time of things.
Finally, consider what about your wiki will set it apart from the many many many many other wikis already out there, and how your design will impact this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I was recently put in charge of the wiki for the development team. The wiki is still in its infancy, so I have a lot of room to work with. It goal is to house internal to the development team. Currently, the main piece of information that the wiki holds is Coding Standards.
What are some best practices your dev team uses for its internal wiki?
What information is important to have on a dev wiki?
If you were to go to the wiki for your dev team what information would you expect to see?
Is there some information that shouldn't go on the wiki even though it seems like a good idea?
-- edit --
Also, is there a good way to organize the information? ( such as by layer ( data, ui), by porject, or other)
Introduction to the source base for new programmers
General documentation (not the API documentation per-se, but more tutorial like things)
Lists of staff / who's doing what and how to reach them
Notes / resources / articles that explain concepts used in the software
Documentation of the build process and the filesystem layout of the codebase
Other things I usually put up there are
Planning / todo lists
Information that is interesting for others to read
Everything else that I feel should be shared
We had a development wiki and it was a great tool. We used it for everything!
When brainstorming new ideas, we'd capture them on the wiki. The low friction nature of the wiki made it easy for anyone in the organization (we were a small startup) to add ideas as they thought of them. We had a high level "brainstorming" page which linked to detailed pages containing a thorough description of each idea.
For each iteration, we'd "move" feature idea items from the "brainstorming" list to the feature list for that iteration. The details of the feature were flushed out to include design and implementation details.
As features were completed, the iteration page became our release notes page - which also included the release tag from our version control system.
We had a bug page that worked very similar to the feature pages. Bug fixes were added to the iteration/release pages as they were worked on/complete.
We also created our user documentation on the wiki and exported those pages it with the release.
As time went on. This tool was viewed more and more valuable. We wound up creating new wikis for different the products the company was working on.
I hope you find your development wiki as useful as we did!
Wikipatterns is a website dedicated to documenting best wiki practices. They also describe anti-patterns and talk about ways to deal with them. I read their book and it was a great asset for me to get a wiki off the ground in a 150+ person organization.
One thing that we stress on our dev wiki is that it is updated when things change.
We don't want our wiki that is intended to provide information and be a central source of collected knowledge to become so out of date that it is useless. As the code is updated, developers are requested to update any related information on the wiki.
Other than Coding Standards, we keep tips and tricks for working with our code base, setup information for new hires, and general environment information.
The hardest part is getting developers to use your wiki. I have some long standing suggestions here: http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted
Getting a Wiki Adopted is Tough
Have a Champion
Remove Objections
Create Content
Enmesh the Wiki In Company Processes
Evangelize
Don't Give Up
Consider Not Using Wiki For Conversations
Just Do It! Don't Wait For a Budget
Have a Transition Plan
Promoting Your Wiki
One good practice is to have the entire documentation and source code for each build available through your wiki. Then developers will go to wiki to access build info and that makes it invaluable.
Wikis can be a valuable resource for software development teams but they are not a silver bullet. It is all too easy to create a Wiki that would rapidly fall into disuse or become grossly outdated.
In my opinion, the key to a successful Wiki is getting the entire team on board. That means getting people away from other resources (and in particular email archives) as knowledge repositories, and offering some incentive for people to contribute.
However, it's also important to not be a format czar: If you have a lot of documents that you generate in, say, MS WORD, it may be ideal to do them all in Wiki format but that takes time and may be annoying if you have diagrams, documents, etc. In those cases, it's better to compromise and let people keep it in word format, as long as the only way to access the newest version is through the Wiki.
If you're not a manager, you need to get a manager on board because it would require some "enforcement".
There has been accumulating research and experience on Wikis and their use in software engineering. You can search the ACM digital library, for example. I am a coorganizer of an annual workshop on wikis for SE and we had several interesting experience reports and there are additional materials in the international symposium on Wikis.
Burndown charts
common setup information for development environments (nice for when new people start)
Specs
Known issues and workarounds with development tools
Come up with some kind of style guide, and teach others how to style stuff. When I was in charge of a corporate wiki, all of the other developers would just write crummy prose that was barely formatted, and looked terrible.
Keep away from things that require discussion. I tried shoehorn in a book review section, but it was too difficult to have others comment on things.
Examples of in house libraries are good. And/or "storyboards" walking a user through a process when MethodX is called.
What are some best practices your dev team uses for its internal wiki?
Make it look nice. I know it doesn't sound important, but if you spend a little time branding it pays off in terms of people actually using it. And uptake is key, or it will just wither and die.
What information is important to have on a dev wiki?
General information about a Project, milestones, delivery dates etc.
Summaries of design decisions/meetings. Important so that you don't re-visit the same areas time and time again.
HowTo guides for general development of current projects (for example, how to develop a new Plugin)
If you were to go to the wiki for your dev team what information would you expect to see?
Project information, who is working on what etc. Design decisions. Also best practices and links to useful sites.
Is there some information that shouldn't go on the wiki even though it seems like a good idea?
Low-level task lists tend to fluctuate and not be kept up-to-date, and can be misleading.
Also, critical communications between departments are better suited to e-mail, THEN the conversation can be copied to the wiki. It's too easy to ignore it otherwise!
Remember that a wiki is interactive. If you're thinking about publishing, as in publishing burndown charts, then you're not thinking far enough. Distributing that information is only part of it.
For instance, rather than having a "Current Burndown Chart" page, create a page for "Burndown Chart for Week of 10-27-2008" and then encourage people to comment on the chart, and what it means, and why you did so poorly that week.
We house and inhouse team wiki. And there we put all the necessary information for each project we are developing:
repositories
addresses for virtual machines
passwords
project documentations
project overview
project status
and anything else we fill needs to be written on a project. And it is the most useful web application we are running (besides Mantis) . On more general pages we put a definition of every taxonomy we are using, general project guidelines, polices, coding and developing practices we use.
It is there, it is simple and effective and I think every team should have one of those.