Benoit St-Pierre wrote:
Hi!
> Suppose you have a closed tournament. You have all the games, except
> one. That one, you're not sure, or you're waiting for the score to come
> in. It's sensible that you enter the header without providing the score
> : you're waiting. Sometimes, it's empty because the game was forfeited,
> or that the player died of a car accident. Whatever : I am choosing
> extreme examples to illustrate the need to have metadata, not to say
> that it's how we should do it regarding this very project.
Actually, I think you're both right. Benoit is right in the
regards that one should have e.g. the header in this case to
know that this game was played or is played at all. (Think
e.g. about incorporating correspondence games. No need for
one player to die, they take long enough without such
issues.)
Pascal is IMHO right as I'd suggest to set up one db that
first collects the games that should make it to the final
CentriScid-DB. And only once they are checked and complete
they should be committed to CentriScid-DB. Therefore, I'd
suggest to organise the build up in two DBs. For a
collaborative efford it might suite best if each
collaborator takes responsibility of his part on the basis
of an event.
> If that's nonsense to you, imagine you have one game that
> finished in time scramble and you put an "etc" at the end
> of the game. You finally get to the final moves : a
> friend noted them. This is in fact the same process as
> correcting a misspelled name, or a misclicked move : you
> change the game score. This is "good enough".
Point is, that such a game should probably be in the
"todo"-db, but make it only then to CentriScid if it is
finished and complete to the best knowledge.
> Or is it ? We have the best practices for CVS when it comes to
> programming. Do we have them when it comes to archiving ?
I think the CVS approach is pretty applicable. Though I'd
suggest the "to be commited" part as accessible. I may, just
as an example, mention how it's done in a major software
project, where I feel the handling is pretty well and
serves the end product best.
They split their software in three sections:
- Stable:
This is software that is debugged and extensively
checked. This is also the version of the software that is
delivered to the general public and the stage of the
release is only defined by one single criterion: _all_
open bugs are closed. At the point of the release this
software is in fact "100% bug free" to the best of the
knowledge of all programmers. Here, only corrections take
place for errors that are found after the release, but no
new stuff is added here ever. That is if some particulary
part of the package is released in version 1.0 and whilst
the lifetime of stable there is a 2.0 and a 3.0 it will
stay at 1.0 till the next _stable_ version is released.
This thing has a pretty slow evolution but you can really
rely on it. Fixing a bug that shows up has a very high
priority.
In CentriScid terminology this would mark _the_ CentriScid
database. Correction of spelling errors would be ok here.
It would contain only games that meet all criteria of the
collectors concerning tag quality (metadata) and
completeness (e.g. for tournaments one could imagine that
"closed tournaments" have to be complete while opens do
not have to.)
- Testing:
Here you have new software that is considered for the next
release lives. It is tested for bugs which are resolved,
new stuff that seems fit for the next release is added
here once it is considered mature enough.
Bug fixing occurs as soon as bugs show up in the next
higher level and they are propagated to testing. From time
to time the input from Unstable is halted, and then once
testing is 100% bug free to the best knowledge of the team
this version is moved on to stable to replace the old
stable branch: a release is made.
In CentriScid this could e.g. be a level where games and
tournaments live that are complete, passed a first check
(e.g. automatic spell correction without any major
problems) and where the games are finished. This could
also be the stage where flags are added if appropriate or
and missing tags come in or get properly normalised.
- Unstable:
This marks the bleeding edge of development. Software in
this area does not necessarily need to work and is likely
to contain bugs. Here major testing takes place and bugs
are fixed.
In CentriScid this would be the part where all games that
should be in the final database should come in. They are
checked for validity of the moves, first checks for
correct metadata are made. Tournaments do not have to be
completed to be entered here, here also games could live
where only the header stub currently exists without any
move and also games and tournaments that are not yet
finished end up here. This component could "harvest" well
known sources and some automatisation how a game comes in
here could apply. E.g. every week TWIC would end up here
or if CB is offering annotated versions of some games they
could also come in here.
If someone out there sees any similarity to the Debian
project this is sheer chance, but unavoidable ;)
> That might not be a great problem for practical chess.
> Not so for documentary pruposes, would say historian like
> Edward Winter says, who regarding Tartakower vs Przepiorka
> said [1] :
> **
>
> This game provides yet another reminder that databases
> cannot be taken on trust, as the first moves are
> frequently given as 1 e4 e6.
In the workflow outlined above Mr. Winter would definitely
work only with "CentriScid Stable". The average user out
there would probably like testing better as this is on an
actual basis with a timespan of about a month. But there may
be well a bunch of users that use actually the "unstable"
because they feel that this is the most actual basis and
slight errors are not that important as they probably do not
want to generate crosstables or do research on the basis of
Mr. Winter.
The above is just a suggestion how it could look like.
Personally, I just found that this little free software
project mentioned did probably the best job out there for
years and offers a suitable solution for everybodies needs.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
