On Tue, Aug 07, 2001 at 10:16:26PM +0800, Stas Bekman wrote:
> [Barrie, I hope you don't mind that I put it on the list, the more people
> contribute the better the outcome :)]
Not at all, I just noticed that others seem to have replied directly and
followed suit.
>
> Something like this: http://perl.apache.org/guide/troubleshooting.html ?
That's what made me think of it. That deals with a lot of the common
ones, I was thinking of something more open-ended that would grow to
contain more symptoms and (where useful) more details on how to fix
things. For instance, including the failures found in a lot of systems
would mean covering various tempalting system failures.
One of the great things about Perl and mod_perl is the diversity, but
it's also daunting to newcomers to identify all the peices and what
might be wrong, especially in a troubleshooting situation.
> The problem with DB, is maintence. When it's flat, people read mostly
> sequentially, point out and fix problems. When it's in the DB, most of the
> items would hardly come up and it's easier to have stale data in there.
> Especially when you knowledge base getting big.
>
> It's also hard to follow the evolution of the DB, since you don't see the
> changes like you do with flat files, as they change with CVS commits.
New and significantly revised entries could be sent to the list, both to
be proofed by area experts and to act as sort of a "FAQ a day" update to
people learning about different sections. Don't want to drive list
traffic up, but hey. Hmmm, sonder if a mod_perl FAQ a day list would
make sense. Kinda your one-a-day Vitamin MP.
> I think I need more convincing points to decide to make it as DB.
I think the biggest points are to make it easy to submitting "articles"
and encourage near real-time peer review, along with structured
searching.
> > Hmmm, since you've already pointed out that printability is not the
> > primary goal, I wonder if we should just take AxKit and it's nascent CMS
> > and start building a knowledge base? The book format is nice for
> > getting spun up to speed, but the knowledge base interface is what might
> > actually cut down on list traffic.
>
> Well, if you don't get to work with XML directly. I sure thing dislike
> maintaining simple documenents in XML. Since you have to use some web
> interface to edit the documents, you have no power of editors like
> vi/emacs, which makes the work much harder.
I don't care about the underlying format, make it a POD variant if you
like.
> > I could even see a search interface on an email address, so when you
> > see a FAQ pop up on-list, a simple forward to [EMAIL PROTECTED] or
> > something would do a search and send you back a message suitable for
> > forwarding to the original poster or something.
>
> This would be a very sensitive change. You don't want to AI replies end up
> on the list, since they won't be correct all the time.
I would suspect that the reply might be a URL for the user to follow.
Probably 20% of all questions on-list are answered by you or Perrin or
others zinging a URL to the relavant section of the guide. Can that
part of you be augmented by an AI?
> > Kinda like the IRC bot purl.
>
> Heh, I'd love to play with infobot (==purl) in the real world. I think
> Kevin said that it's ready for working outside IRC.
:-).
> Sure, there is no limit on how the third book should look. As long as it's
> manageable and useful for users. The first two books will play it strict.
> The third one is very flexible.
Agreed.
> Yup, exactly. seems very exciting if actually get to implement it. Then
> the world domation will be finally a next chapter. :)
The winners get to write the history books ;-).
- Barrie
