On Tue, 7 Aug 2001, Barrie Slaymaker wrote:
> 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.
yup, whoever wants to dive in, please keep the posts on the list. Don't be
shy.
> > 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.
When creating this page, I've followed a simple rule: when somebody asks a
new question and gets an answer, I ignore it, unless the answer is really
interesting and covers more than the question's scope. When the same
question gets repeated, I add the Q&A to the troubleshooting chapter.
Thus I've avoided having this page bloated.
I believe it's probably not a good idea to collect all Q&As, because the
content will become very hard to maintain and harder to navigate.
> 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.
Not if they use the search interface, you type in your symptom and you
come up with hits. Let's say you see the error: "Apache.pm failed to
load!", I go to the search input, type in the symptom and the first hit
that comes is
http://thingy.kcilink.com/modperlguide/troubleshooting/_Apache_pm_failed_to_load_.html
May be the problem is in educating users how to use, and not how to store
the data.
I've never claimed the the current guide is easy to navigate, unless you
read it all. But I think the search engine on the split version of the
guide does a great job. I use it quite a lot by myself.
> > 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.
This is a hard issue.
A. If you create a new list, most of the people won't get on it, because
they don't want extra traffic. I assume that this list is not only for
sending the Q&A items, but discussing them as well.
B. If you do this on the main list, people will get unsubscribed, because
of the heavy traffic.
I guess we could have modperl-daily-faq list ala [EMAIL PROTECTED]
(which is mainly dead). But this doesn't solve the problem of where the
FAQ items are to be discussed.
Another problem is how to avoid overlapping with the book/guide like
materials. In http://perl.apache.org/guide/troubleshooting.html I've
solved this mostly by listing the symptoms only and linking to the
portiongs of the guide for the explanations.
Having the knowledge base disconnected from the main material will make
this duplication removal and maintance overhead very hard.
> > 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.
What's the problem to submit articles right now? You want something to be
added to the guide, submit to the list, get peer review, get someone to
store the cleaned version in the guide, then update the DB. I still prefer
to have it flat, while easily convertable to any flexible format
imaginable.
The idea of throwing many items into DB simple doesn't work, because many
records in this database will want to preserve some order between them.
For example look at the most disconnected items in the troubleshooting
chapter. I've the items sorted by 'configuration', 'build', 'startup',
'run time'... categories, so you can easily narrow your search, by jumping
to the right section. I don't say you cannot do this with DB approach, but
then it gets complicated as you lose some of the flexibility.
In any case, as long as we build the knowledge base in a way that can be
easily converted from one format to another without doing any manual
adjustments, we can fine tune things as we go. I'd hate to find things not
taking off the ground because we cannot agree on 'how', while we know
'what'. (which is why we still have a crappy web site :(
> > > 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?
While it sounds nice, there is a big problem with this approach. Since we
are all volunteers on this list, nobody promises to answer every email. I
believe that currently most of the questions get answered, without talking
about the values of the replies. Now if you have an AI body attempting to
answer emails, people will simply skip the answered emails, no matter how
good the AI answer was. Or am I wrong.
I think the solution should be similar to your proposal, but shouldn't
change the way the list works. We should provide this interface online and
educate users to use it, so instead of sending email to the list in first
place, they are to be advised to use this AI interface and see if they
come up with an answer without bothering the list. If they fail they
should contact the list and possibly try to discuss why AI has failed to
help them out, so we can improve the knowledge base.
But this is exactly what users are supposed to do now. Before you ask the
list, try to search the guide and mailing list archives. So basically we
just want to improve the interface and AI factor of these two already
existing knowledge bases.
Another interesting idea would be to involve Ken Williams' AI::Categorize
on the whole archive of the list, and see if can completely automate
things, without doing anything at all. If we can dynamically assign
attributes to all posts and threads, this would be the most invaluable
knowledge base. Ken?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
