[Bug-gnupedia] Proposal for a near-term battleplan

[Bryce Harrington]

One thing I've found useful in other project's I've worked on, is to lay
out a sort of step-by-step plan, for people to follow.  From the
discussion that's gone on today it's my suspicion that this would be
helpful here too.  Here's an admittedly extremely rudimentary plan off
the top of my head.  I know Hector must be very busy, but maybe this'd
give him something to work from...


Phase 0
-------
Article submissions are accepted by Hector and held.

[This apparently is the "IS" condition we're at now; I think it would be
valuable to let people know that this is what is actually going on.]

Phase 1 ------- Hector receives article submissions via email.  A
directory on a web server is used to store these articles.  Each article
and whatever parts, images, sounds, etc. is placed in its own
subdirectory, named arbitrarily as decided by Hector.

Phase 2
-------
A Perl script is obtained which allows upload of articles directly to
the web server.  Articles are placed into a "pending" folder, and 4-8
administrators are charged with the duty of moving these into a public
folder.  Only submissions which are clearly abusive are refused at this
point.

[The above is suggested largely because I already have code which will
perform the above segregated upload functionality, which we use at
WorldForge, and can be put into place within a week.  It creates a
flatfile list of all submissions, presently.]

Phase 3
-------
A "verification script" is created which is used to check each and every
submission to ensure it meets whatever standards are desired by the
group.  These prerequisites are simple and fair, and are published
clearly, so that all may see what needs be done to get their docs
accepted.  ALL writings which pass these verifiers are accepted.

The script from phase 2 is modified such that instead of writing to a
flat file, it writes its indexing data to individual "header" files.
These could either be XML header files, or reside in a database (or
both!)  They could also be part of the submitted data file.  Who can
say?  But in any case, the header info will be there *somewhere*.

Also, a "search script" is written, which uses the database, or else
merely 'greps' all of the source files, and allows users to locate the
data they are searching for.

Phase 4
-------
Whatever approach we might take, at this point we can (and should)
insist on some thorough architecture/design documentation, if it hasn't
been written already.

The search system should be much more powerful.  In addition to
arbitrary topic-search, it should support at least one hierarchical
searching capability (e.g., I should be able to click on "history" and
then "greek", and be able to find some items regarding "Greek
Architecture".  Most of these features ought to be mostly interface
issues. 

Phase 5
-------
This phase, and those beyond, will ivolve creation and deployment of the
perfect system for people to follow...

Bryce