A good pilot for a wiki in your environment may be to use the wiki for scratch work and more note-oriented information, e.g., howto's, common tasks. We rely heavily on ours for that. If people take to it, and they will, then you can start pushing it harder for places where it fits.
After reading this thread I wonder if we could plug our wiki into our project management solution.. The wiki is great for notes and general comments but, for us, not so good for really good project management. You can plot out a timeline in a wiki, sure, but you have to do a lot of the grunt work yourself to watch what's going on if you do it that way. -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author, "Best Practices for Managing Linux and UNIX Servers" http://www.puryear-it.com/pubs/linux-unix-best-practices Identity Management, LDAP, and Linux Integration CM Banker wrote: > On Nov 20, 2007 6:38 PM, Scott Harney <scotth at scottharney.com> wrote: > >> You know, you would think that, but in practical use, we really haven't >> found that to be true. I suppose if your organization has strict >> documentation format requirements, this wouldn't be a good fit. And you >> could break up a twiki into multiple "webs" each with its own groups of >> authors/editors who control the content underneath. > > My organization is in the formative stage of document management. > We're in two groups : one that has an effective, predictable but > inefficient means of documentation ( document templates & directory > structure for projects) and the other that is becoming more formal in > its process due to project growth and team growth. (Very small shop > growing fast in work and talent) > > The first group's documentation style/need/contents reflect a > predictable process by capturing named rigid artifacts and > correspondences. They do the same thing-ish over and over. On the > other hand, the formative group is a development group trying to : > insure all developers understand what they're working on (background & > constantly shifting requirements), keep track of projects (project > management), manage defects, and feed the process that generates user > documentation. Our biggest challenge is a huge critical mass of > domain & system knowledge is required just to start doing any > practical development. > > The systems we deal with are complex (but not that complicated), and > the nature of the information is difficult to chain in an exposed > predictable manner. (I feel tired just thinking about it). (Now > that I think of it, a wiki, with clonable sections and some initial > organization is looking good for this stuff). Maintaining proper > currency with the documents and schedules is a bear. > >> We've been using twiki (http://twiki.org) on our team for about two >> years now. Our team consists of unix, mainframe and storage >> administrators and engineers. We have a multitude of projects as well >> as daily operational responsibilities to keep track of and while people >> in the group have their particular points of focus, we all need to be >> aware of how to pick up some of the other responsibilities. >> >> We use numerous add-ons, some of which shipped with it, and some of >> which we added after the fact > > I looked over the url - this impresses me as a fairly mature > implementation of a wiki. Even a doxy plugin. > > Of course, making developers churn out useful, appropriately detailed > documents is like pulling teeth from a mule, and this, of course, is > easier than making them use a formal system. :-) > > Scott, Do you mind if I contact you off list for a couple of other questions? > > Thanks, > > -CMB > > _______________________________________________ > General mailing list > General at brlug.net > http://mail.brlug.net/mailman/listinfo/general_brlug.net
