[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oswg] Linux Knowledge Base project (fwd)




I think these are all excellent points and are issues that we'll have to
deal with sooner or later.  It reminds me of our earlier discussions of
using nntp or DNS as our mirroring/transport protocol.

One thing I've already noticed is that #3 is very true.  There is a large
number of people willing to translate content into other languages.  This
should probably be high on our list of things to do.  #1 is something
we'll also have to deal with soon, though not right away.  I think it is a
nice to have, but not completely necessary.  #2 (mirroring) is probably
the least of our concerns.

Still though, my stance stays the same: Let's cross that bridge when we
get to it.   

On Tue, 24 Aug 1999, Roger Dingledine wrote:

> Forwarded message:
> >From owner-techwriters@linuxchix.org  Tue Aug 24 14:44:23 1999
> Date: Tue, 24 Aug 1999 16:01:15 +0100
> From: Nik Clayton <nik@nothing-going-on.demon.co.uk>
> To: techwriters@linuxchix.org
> Subject: Re: [oswg] Linux Knowledge Base project
> Reply-To: techwriters@linuxchix.org
> 
> Andrew, 
> 
> A couple of comments about technical issues that you (and anyone else
> considering implementing something like this) might want to consider.
> 
> On Sat, Aug 21, 1999 at 12:32:22AM +0100, Andrew Wood wrote:
> > Since I don't have a very good connection to the Internet I was thinking of
> > implementing this as an email discussion group with archives available on
> > the web, as well as perhaps having "submit a question" buttons on the web
> > page for others' convenience; sorting through email is easier for me than
> > browsing web pages.  Not sure how workable this would be in practice though.
> > 
> > As usual: Thoughts?
> 
> >From my experiences on the FreeBSD project, you need to be aware of a couple
> of problems, and at least have some idea of how to solve them before you
> begin:
> 
>  1.  Revision control.  How are you going to track changes to the questions
>      (and the answers) so that you can properly attribute changes to 
>      individuals.
> 
>  2.  Mirroring.  Resources like this are much more useful if they can be
>      mirrored.  Both in the large sense of having multiple servers around
>      the globe, so that people can be directed to the closest server to them
>      as necessary, and in the smaller sense of people maintaining local 
>      mirrors of the information on their computers.  For many people it's
>      cheaper to maintain a local copy of the information than it is to fire
>      up a connection to the Internet every time they want to check something.
> 
>  3.  Multiple language support.  If there's one thing working on the FreeBSD
>      Documentation Project has taught me is that there are huge numbers of
>      people in non-English speaking countries who are willing to put in 
>      immense amount of effort to translate documentation from English to 
>      their native language.  The FreeBSD Documentation Project has sibling
>      projects converting the documentation to Japanese, Spanish, Russian, 
>      Chinese, and French, to name just a few. 
> 
> A lot of people, when faced with the sort of problem you're describing think
> that it's relatively easy, and just a case of a few web pages, and some
> PHP, Perl, or Python linking to a backend MySQL or Postgres database.  I 
> hope the three points above show why this isn't quite that easy, and that
> spending some time designing this now will save a lot of pain later.
> 
> N
> -- 
>  [intentional self-reference] can be easily accommodated using a blessed,
>  non-self-referential dummy head-node whose own object destructor severs
>  the links.
>     -- Tom Christiansen in <375143b5@cs.colorado.edu>
> 

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.