On Tue, Jan 03, 2006 at 09:55:41PM -0700, Aaron J. Seigo wrote: > On Tuesday 03 January 2006 21:01, Bastian, Waldo wrote: > > There would be a natural motivation in the sense that everyone will be > > documenting those parts of the system that they have a natural interest > > in already anyway. > > given that we don't have much of this documentation right now (i'm thinking > of > high-level docu (e.g. "how to print") versus API docu, which we do a good but > not stellar job with), i don't know if this is realistic?
I was involved in the very, very early days of Wikipedia, so I do know that natural motivation for writing documentation exists and can be harnessed, but I also know it's really, really difficult to get things up off the ground, and takes dozens of extremely crazy^H^H^H^H^H visionary people to get it to the snowball point. Wikipedia's the exception, not the rule; I've been involved in a dozen wiki efforts for every one that actually could be called a success. Incidentally, I'm having some experience right now with this documentation portal in a microcosm, for the NFSv4 testing effort (http://wiki.linux-nfs.org). We've been collecting documentation to help answer questions that NFSv4 testers and deployers might have. It's working, but it's very slow going. This may be because NFS is a fairly dry topic compared with something exciting like RUDI or Klik or Inkscape, but I think that makes this a good analog to what we're talking about here. The exciting stuff has no trouble getting documented; it's this core infrastructure bread and butter stuff where the documentation effort is really needed. Anyway, I guess my point is that I think there's some stuff where there is natural motivation to write documentation, but the stuff that really *needs* to be documented may not have natural motivation, so the best strategy would be one that had a built-in motivation for getting the bread and butter items documented. > > If OSDL would generate the questions I'm sure that the individual > > projects will manage to come up with answers, after all, these are the > > same issues that are being asked and answered on mailinglists already. > > The only difference is that with this infrastructure such knowledge > > would be much more accessible. > > how many questions on mailing lists are of the "how do i use this particular > set of functions/classes in libfoo?" variety versus broader, topic-wide > queries like "how do i print?" or "what are the IPC options available and how > do i use them from my application?" Or for example, a question I happened to have today - what is the best practices being used for provisioning multiple client machines? I had a bunch of (gentoo-based) test systems at work that I have to keep up to date, and have just got 10 more bare systems that I need to install. We have typically just been using system imager, but I'm curious what other companies and organizations use. Is there a best practice? If not, what are the pros and cons of the various options? I figured this was something that lots and lots of people have already run into, so searched a bit online (keyworded with gentoo, debian, and ubuntu) but found very little that I would trust to be unbiased information. Wikipedia had an article on provisioning but it only scratched the surface. Bryce
_______________________________________________ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects