Comments/Ratings for a Single Item

In relation to '10' entries, I was wondering if my 'The Bermuda Chess
Angle' was going to be added to the contest.  It was submitted over a
month ago.

I sent one game >(one month ago), and I know there are other persons in the
same case. Lots of work?. Is the Contest stopped?.

I see nine entries so far.  Perhaps the editors are fighting over who gets
to  be the lucky 10th entry. :-)

We have the entries for everyone who's posted, what's lacking is editors
with time and energy.  I'm afraid most of us are kind of burnt out.

This isn't some sort of dramatic foreshadowing of the closing of the CVP
in the near future due to lack of available manpower, is it?  Because if
it was, that would be, like, y'know, *totally* uncool.

I'd like to add my comment on this topic as a CVP member and editor. I
really enjoy editor work for CVP, however, I have not had the time lately.
I have not made any moves in my e-mail and online games in weeks either.
Burn-out? Yes, there is an element of that too, even when the work is
enjoyable. I have not dropped out, however, and hope to continue to help.


What we need is more volunteers to share the work. Volunteers need to
share some basic interests; chess, chess variants, and basic knowledge of
HTML editing; to enable them to create, edit, and post pages to the site
-- as well as the time to do it, of course. Something else: editors all
work at their own pace. There are no assignments. 

Unfortunately, the CVP being an all-volunteer organization, if volunteer
time is in short supply, very worthy submittals get delayed, even contest
submittals. Unfortunately, this is the case right now. The CVP is not
out-of-business, just in need of volunteers. Any ideas are welcome.

I do not support any wiki idea, unless the inventor of any given game has
the control over that game's page.  And even then, I'm not wild about
the idea.

Here's an alternate idea, although it would require some additional PHP
code for running the site... Basically, the idea would be that any member,
not just an editor, would be able to upload pages (to a special directory)
and enter them into the database, but they would not be visible to the
community at large until an editor views the submission to ensure proper
formatting, good taste, etc.  If the editor approves the submission, he
uses the PHP system to 'activate' the page, which moves it to a
permanent directory of the editor's designation and makes it visible to
the world.  If there are problems, the editor rejects it with a note about
why.  Then the user may fix the problems and re-submit.  Yes, this requires
more of users who wish to submit in this fashion, but such people could
also enjoy quicker response times (assuming they get it right, of course,
but the same inventors tend to produce multiple games; the prolific
inventors will get good at it.)

I think that whatever system we choose to use in the near future, we'll
just need more editors to run it.  Also, I think the wiki idea wouldn't be
that great.  If you want a CV Wiki, enter some pages into the Wikipedia.

I'd volunteer to be an editor, myself, if I knew enough HTML to be useful.

I like Greg's idea also.  

What could be created is a submission page which is basically a
fill-in-the-blank form.  The framework of such a page would be the source
of much debate, and should be handle on a separate comment thread.

I also like Greg's idea. Perhaps the PHP could incorporate CVP standard
page elements. (More work for David! -- by the way, David does a
tremendous amount behind the scenes to make the site run better.) Editors
could view the result, amend where necessary, or suggest improvements to
the author, then approve for posting. Perhaps the final location of the
files could be facilitated by the indexing system.

I was not envisioning this new submission system automatically formatting
the text into the CVP template; that would be a lot of work to program,
and the standard outline, 'overview', 'rules', 'equipment', etc, is
probably not flexible enough to accomodate the wide assortment of games
being submitted.  It might be nice to expirement with someday, though ...


For a first version, I would do this: 
The first page takes basic database information about the game (name,
one-line description, number of ranks, number of files, number of cells,
...).  At this point I would have the database search, and reject the name
if it is a duplicate of the name of an existing game (including both games
already public and games still pending review.)  If all information has
been entered and there are no conflicts with existing games, then it
creates a sub-directory for it under the temp directory and instructs the
user to FTP upload the HTML page and any images to which it refers into
the newly created directory and click 'OK' when finished.  When the user
clicks OK, he is given the URL to the newly uploaded page, and asked
whether to proceed with the submission or upload again (in case there was
a problem.)  When the user indicates he is ready to proceed, an
email is sent to the editors notifying them of the new submission (and
giving them the URL.)  The editor then uses a PHP page to accept or
reject.  If accepted, the editor specifies the category of the game
('large variant', 'historical variant', etc.) and the program will
then move the game's directory to the appropriate permanent location.  If
rejected, the editor types a description of what is wrong, and the user is
notified, and can FTP up improved versions.  I would suggest the editors
NOT fix mistakes in the submissions; reject them with explaination and
make the users fix them.  This way the people who submit games get good at
it, (after a little practice,) and it would require very little time of the
editors.

Further thoughts on Greg's idea. The suggestion to have the user upload
completed pages to a temporary folder for acceptance or rejection with
comment presents the following issues. 

1) FTP upload will work only for submittals in HTML; most submittals are
made in Word format or simple text. Much of the editor's work involves
converting the original submittal to HTML. 

2) Authors not familiar with CVP will often offer submittals that are
difficult to follow. Much of of the editor's work is taking the original
text and re-organizing it into more standard sections to allow the reader
to more easily follow the description. As Greg notes, more experienced
authors do not need this editing and sometimes would be unduly constrained
by using standard section headers. But, this is the minority. 

3) Sometimes, basic English needs correction.

4) Sometimes, the editor can make worthwhile enhacements, such as
appropriate hyperlinks and adding board images created with Game Courier
or Hans' GIF's.

5) HTML submittals often have special header tags that are not compatible 
with the CVP standard. Very few include the standard CVP header and footer tags. 
Editors usually have to make the necessary changes.

In other words, the editor's job is not so simple as accepting or
rejecting a submittal. This may work for some, but for many the learning
curve may be too much. This is why I suggested a form to fill out, if you
will. But, as Greg points out, this would take a lot of programming. I
think Dave's input on what is practical and worthwhile is key on this
issue.

Yes, I completely understand all of Tony's concerns, and perhaps I should
clarify my thoughts.  I only propose the automated submission, as I have
described, as an alternative to the normal process.  Many, many people
will not be able to take advantage of the automated process for exactly
the reasons Tony enumerates.  At least in the early stages of its
development, the automated system would only be used by a few of us, but
we would go through the trouble to use it because our submissions would
'go live' far more quickly.  Even if only a few of us use it, it still
reduces workload on the editors, not only because the entries of those who
use it will require less work, but also because it allows those of us who
know how to use the system but are not editors to help others by 'doing
the heavy lifting' of translating to HTML, fixing English errors,
phrasing things better, etc.  People such as myself would be able to do
the work for the submissions of others (when asked) without being
designated an editor.  I already can (and have) made Game Courier presets
for people, and I ask Fergus to make 'em public when ready; this would
allow a similar process for game descriptions.  But much of the existing
work of the editors will remain in the short-term.

Greg's clarification makes a lot of sense. This approach may work. In
other words, certain expert users can assist with editing work through an
expedited submittal process.

I have been a junior editor, and I just do not have the HTML skills to
build new pages efficiently.  [And yes, burnout was a factor.  I was
pretty much finished off by judging the 84-square contest.]  However, I
have no problem reviewing pages already built for content, and flagging
them approved, since that would only take a few minutes.
Submitted pages would need more than two flags.  You'd need:
- accepted
- rejected
- needs work by author
- needs work by editor
and also comment fields, so, for example, another editor would know why I
thought more work was needed, or why a page was unacceptable.

I think the simplest thing to do is to setup a form that allows members to
upload new content, including both HTML files and graphics, to a special
directory. The script that handles this could be setup to reject anything
that isn't HTML or graphics, and it might even be programmed to do some
preliminary validation of HTML files to make sure it follows our
templates. For example, it could check for the presence of certain strings
in the file. To make this even more sophisticated, we could allow members
to upload new HTML files and graphics anywhere, or at least in any
directory designated for game descriptions, and to also allow whoever
originally uploaded a new file to upload updates of it. This would require
keeping track of who originally uploaded what. Files newly uploaded in this
manner could be kept hidden until approved by an editor, and the uploading
script could also place new pages and graphics on a What's New page
accessible only to editors.

Many submissions need only be presented in TXT format.  With the proper
spacing and font sizes, they can be placed in a standard HTML page with
the PRE command.

I would not recommend freely allowing the upload of graphics, since this
can seriously eat up webspace(and there are individuals who will abuse
this privilege).  Instead, the potential graphics could be demonstrated
with ASCII diagrams.  And suggestions for the potential graphics, or the
web adress of such(usually the authors own homepage, or some other off
site), could be included for the editor.  Or the graphics might be sent
upon request by the editor in a ZIP file, and in a specific format(such
as GIF).  The submission should have the file names of the graphics for
easy reference.

The use of PRE tags is a shortcut I would prefer we avoid. Its use should
be limited to ASCII diagrams. As for stopping unlimited uploading of
graphics files, we could have the script that handles the uploads verify
that any uploaded graphic image appears in an IMG tag in a corresponding
HTML file, and if need be, we could also limit the new images that appear
in a file. I would recommend a limit of 1 JPG (which may be used for the
setup diagram) and 12 small GIFs (which may be used for pieces). Or we
could even limit it to 1 GIF diagram and insist that all other images on
the page already exist on our site.

Limiting it to 1 image would be very restricting, and I really doubt that
unreasonable image uploading would be a problem.  If anyone does include
far too much material (because they are putting up scanned pages, or
whatever,) that would be a basis for rejecting the submission.  If there
must be a hard limit for some reason, how about making it a size limit,
not a limit on the number or type of files.  Even then, some really large
or comlicated games may require more.  

This is the kind of thing that I believe is best addressed when it becomes
a problem, since I think that there is a very good chance that it never
will.  Even at 100,000KB per game, which is at least 100x more than the
average size, an 80 GB drive (about $50) would still hold over eight
hundred thousand (800,000) games!!!

The limit might be the actual memory size of the graphics submitted.  This
would only apply to any new graphics.  So the more existing(on-site and
off-site) graphics which are referenced, the more individual and specific
graphics may be submitted.  This would allow the author to decide the
number and size of the individual files.

And this maximum memory size could be applicable to the entire webpage
submission.  Exactly what is the largest variant webpage on this site? 
Including any that is multi-page.

Actually, the large pages are due to unusual attachments, such as PDF
files, for information not convertible to HTML. The largest I recall was
about 2MB. Most are far smaller.