Let's see what we can do with M1, those <CG> pid's which are new, as compared to the Aug 2014 snapshot.

Sort by N_games to prioritize, and print out those without FIDE id. At the top of the list, with 13 new games is:

Leo Zhang

But his bio has very little for a player with 13 games. In particular no dob or FIDE card (despite the games being very recent).

So, M1 can be used as a quality control diagnostic.

More details (and links for dob, FIDE, etc.) can be found here:

Silvester Sipos

It's really not hard to find this card:

<CG> vacuums up lots of tournaments, and so introduces new players all the time. Undoubtedly, the games comes from various sources.

Sometimes the source will include the FIDE id in the PGN. Great - we get the basic bio there, i.e. dob and FIDE card (with collation-name).

But other sources, like TWIC, may not include the FIDE id. But it may include the player's rating.

<CG> should endeavor to take a moment or two to locate the player's FIDE card (which must exist, else there won't be a rating).

If <CG> can't do this, it should log the player in some list and notice should be provided on the Bistro.

I could give many examples, here are but a few (see my blog post cited above for more):

Alina L'Ami

Earlier she was <Alina Motoc (50280)>.

There are two issues here - how to do the merge, and what name should be used?

For the merger - which <CG> pid gets deleted? The one with fewer games and the "right" name, or the one with the bulk of the games and the maiden name.

Actually, the question of the "right" name is the main point.

Other women who change their name have their maiden name propagated into their new name:

Niina (Koskela) Sammalvuo

Earlier she was <Niina Koskela (36097)>.

I would be inclined to adopt a variant of the latter convention - somehow incorporate the women's maiden name into her name. In the US we generally do this without the parentheses, the maiden name becoming a middle name.

There is another issue raised by this example. The earlier <CG> player had additional information which seems to have been deleted during the change.

Her dob has disappeared (1971.08.08), as has her nationality, and country of orgin.

That is the correct propagation of the rating ATH during a merge.

Case in point:

Silvia Carolina (Mazariegos) Kummerfeld

Current ATH is 2012.

But the earlier version, <Carolina Mazariego (53086)> had an ATH of 2086.

Surely the ATH should be max(ATH_1,ATH_2) during a merge, right? So it should never go down.

And in case doubt remains:

http://ratings.fide.com/id.phtml?ev...

Yes, 2012 is an underestimate of this player's ATH.

Well, that's enough for now. I was hoping that my blog post could have been perused by others to find these issues, but it's just as well I start the ball rolling.

My concern is that by flooding the forum like this I've diluted the impact.

First let me say I'm relieved that the missing female-settings was a mirage. If I learn that there's a chance that data is being corrupted, everything else must take a back seat until an explanation is found.

Moving on:

<For the merger - which <CG> pid gets deleted? The one with fewer games and the "right" name, or the one with the bulk of the games and the maiden name.>

That's complicated. The admin has to make a decision based on multiple factors:

(1) older PIDs are preferred to newer ones (because they are more likely to be linked to elsewhere on the site).

(2) a page with a good biography is preferred over one with a bad one, or without one..

(3) if there is discussion on one of the pages and not the other we prefer to preserve that (or not, depending on what it is.) Posts can even be moved if really necessary, but kibitzes are often scrubbed in a player merge.

About Mrs. Kummerfeld who lost rating points during a merge, it's actually up to the admin to reset the rating properly. So that must have been an oversight by Sargon, although in his defense, the admin software is pretty shoddy to not do that automatically.

<<CG> should endeavor to take a moment or two to locate the player's FIDE card (which must exist, else there won't be a rating).

If <CG> can't do this, it should log the player in some list and notice should be provided on the Bistro.

Agreed?>

Well, yes and no.

For one thing, it's not guaranteed that we can find FIDE cards on all players who are new to the database. When we cover events like the US Open there we'll see many players who literally signed up yesterday to the USCF. FIDE won't know anything about them.

I don't agree CG should do this, because we can't. When we import 300 games from a giant open, we can't pay somebody to go game by game and research every 1200 rated player who is new us.

Furthermore, consider that after we process a tournament like that, we often run a program to scrub out the games of players under 2200, within a set of constraints. The program that deletes games is very cautious. It does some clever things, like checks to see if there's a lot of kibitzing on the player's page. If there is, then the game is spared. It also makes sure that the game isn't being discussed or in any collections, because sometimes even games between novices can be interesting and/or funny.

As far as the notion <it should log the player in some list and notice should be provided on the Bistro>, in a way this is already happening, and working quite well.

I can tell that at least two editors are using our playerlist.txt file now to check for new additions at the end. This is obvious because a brand new player is added and within hours they have a FIDE # and a terse biography.

But then, maybe weeks later, comes the reaper's scythe to delete games between two 1200s, and this player's one and only game vanishes. But it's OK, because we retain the player record. We still know when they were born, what federation they play for, their full name, their FIDE #, and anything else the CG editor added.

So this explains a lot of what you might have been wondering about M0 and M1. There is an ebb and flow of players into the database. We import a giant tournament and get 200 new players, then later we purge games and 100 players are deleted. This has a much bigger impact than the occasional merging of duplicate records by admins.

All these issues immediately surface when comparing the two snapshots.

Let me re-read your post at least once more, or maybe twice, before I address the details.

OK, just one point right now.

I'm a little concerned about having players just disappear, especially if the kibitzing goes with it.

Isn't there a way to allow the old player info to remain with a big fat pointer to the new page? I don't think CG is planning on reusing pid's, so that's not an issue.

Perhaps a defunct flag in the player's list (or even make the pid negative).

Perhaps a defunct flag isn't quite enough.

I can see two different situations - one where a player is just outright deleted, for whatever, once and for all.

An example could be a piece of fiction that never should have been submitted, etc. Another example could be a dumb typo that created the player. Fix it, and forget it.

But the other situation is for a name that once was legitimate. In this case there might be future games submitted under this name.

Or consider this, suppose I'm working on an old snapshot and submit a game to <CG> with a ChessgamesWhiteID that's was valid yesterday, but is defunct today.

This <CG> player just disappears without an "official" trace...

< 54065 / $ 0 Christoph Wisnewski (1980.04.09) DE -- Y M 2428 / 43>

That's a player with 43 games, and a published author (<Play 1...Nc6!>).

It would be very helpful to have a forwarding link show up under the old name, especially given that it will be in circulation one way or the other for a long time.

I was wondering what happened to this player - and it took a little more than just a causal Google search to find the new name <Scheerer>. The old Aug 2014 snapshot only had 2 games under that name:

< 131574 / $ 4647327 Christoph Scheerer () -- -- Y M 2422 / 2>

This is a biographical question to be raised for rewriting the player's name in the PGN of the older games. I'm guessing that <CG> just uses the player's contemporary name (i.e. today's name).

I remember well this little bit of graffiti written on a doorway from my first days in college.

So, the question I ask <CG> concerns finding the FIDE card for players.

I just spent 10-15 minutes doing a few. Most of the time was spent finding the player on <CG>. The google search was usually very quick to get the FIDE card.

These players all have over 100 games on <CG>, and usually somebody cared enough to get the exact dob. But none of them had a FIDE card on <CG> back in Aug 2014. Only Soltis was updated between now and then.

I did 9 players, those with the most games. Soltis was already found, but let's count him. I missed 3, but found 6 of them.

All in just a few moments of work with hard any name mangling (only Morgardo). <CG> could automatically do this with a program, given the published FIDE lists.

And we aren't talking about 1200-rated players who just joined a USCF tournament for the first time. We're talking about established players with >100 games on <CG>.

So, here's my contribution for tonight:

Klaus Viktor Darga (kibitz #20)

Jonathan Penrose (kibitz #66)

Sebastien Feller (kibitz #128)

Alexander Kochyev (kibitz #5)

Andrew Soltis (kibitz #130)

Eldis Cobo Arteaga (kibitz #8)

Juan Sebastian Morgado (kibitz #2)

I was trying to make a point though - that <CG> should be doing the FIDE linkage as automatically as possible.

Here's the rest of the (N_games >= 100 games) list:

Richard Biolek (kibitz #5)

Wolfgang Riemer (kibitz #1)

The notion of linking a defunct record to the new record has crossed my mind. It would require a field "newpid" to be added to so-called 'deleted' records, so that if we look up a player and that field is set, we redirect to the new one. A neat trick. But it's never very notable players who get caught up in these things. Bobby Fischer's PID has been 19233 since December of 2001 and we're never going to change it. It's the more obscure cases where this would home in handy.

Back in Aug of last year, I didn't have the "situational" awareness to really understand all the ramifications.

Even when it seems simple it often isn't.

One would think that if a player's page has a ATH rating (ATH = All Time High), that would imply the player would have a FIDE card.

I mean, how else could there be a rating.

Well, some biographer could have added a USCF or ICCF rating. Not often done, but possible.

And there's the very unfortunate fact that FIDE deletes a player's card after they die. So, only living players should be searched. But <CG> might not yet be aware of a player's death, though FIDE could be.

Of course, there's always the issue of a player changing their name, and so FIDE or <CG> could be out of synch.

But even if you get though all of that, you might have two or three thousand updates to do!

I have a suggestion that might be considered elitist but that might alleviate the problem somewhat. It is very easy (and free) to establish an account at <chessgames.com> and that's as it should be. But posting could be considered a privilege. So I suggest that you consider not allowing a regular (i.e. free) account to post (they could still read all posts and take advantage of other currently free activities) and establishing a Kibitzing membership account type for a nominal fee, say US $ 5.00 or US $ 10.00 yearly, that will give the member the privilege of posting, although posting in certain forums like the Kibitzer's Café might still be allowed for a regular (free) member. You might also want to consider also giving such a Kibitzing account a subset of the Premium account privileges like having an avatar if you think that might increase the desirability of having a Kibitzing account. Premium membership would retain the posting privilege at no additional cost.

This will at least discourage members from opening alternate accounts for the purpose of sockpuppetry. Valid alternate accounts for the reasons you describe in you kibitzing rules (which are probably not many) could apply for a dispensation and waiver of the yearly fee after verification.