Please stop this detrimental policy of allowing pre-1700 GEDCOMPARE

+10 votes
321 views

Enough is enough, Please stop the GEDCOMPARE pre-1700 [!] creation of uneccesary duplicates of existing validated & in the process of being researched profiles.

See this import {Please Klick} to see that it also creates bugs in the prefix field.

It took me near 3 hours to work through this bio collating all the data (and there are loads of other duplicates made in just this one GEDCOMPARE) in order to collate the socalled 'facts'. 

This policy if allowed to continue is really detrimental to WikiTree, is dis-qualifiying the other improvements made such as the recent https://www.wikitree.com/g2g/877280/did-you-notice-the-changes-to-profiles-on-mobile-devices that I really do not have the energy or will to even answer to.

WikiTree profile: Aeltje Janse van Rensburg
in Policy and Style by Philip van der Walt G2G6 Pilot (158k points)
retagged by Robin Lee
That edit looks like it was done by WikiTree X, not GEDCOMpare. Either way, if a user has the pre-1700 badge, then they should be able to create or edit pre-1700 profiles they shouldn't be limited in how they create those profiles.

So then why give someone a pre-1700 bagde when their WikiTree membership is not more than a few days old. Again (and this is really now getting to be an old repeating issue - and with this I imply - J'accuse - those that gave me a down vote on this post) - it is a systemic failure.

Systemic. 

It is not about problems with members. In this case [this specific new WikiTree member] everything works according to the Systemic Protocol (see https://www.wikitree.com/wiki/Smit-392 and his homepage as evidence). It is about something else. Adjusting Policy. And for that Leadership and Insight is required.

Again, both examples you have given have nothing to do with GEDCOMpare.

If you think a user certified before they are ready -- help educate them, or go through the problem with members process so they can be assigned a mentor. Some experienced genealogists will have no issue adding pre-1700 profiles the same day they join WikiTree, and some users will still not be ready after months of working on WikiTree. So putting an arbitrary time limit isn't going to help.
I so disagree with you on this - you are actually suggesting allocating a mentor to every new WikiTreer? Instead of for example allocating badges according to [proven] track record?

2 Answers

+8 votes
 
Best answer

I have to say that I am a bit puzzled on this.

The edit you show appears to be a merge that was completed (Van der Merwe-3754 into Schalck-10), and of the profiles merged, it does not appear the data you show ever originated from a GEDCOM import (see here where the profile was created and then data imported from FamilySearch Family Tree LXQ2-W4H).

If this merge created any massive errors or changes to data, it could have easily been reverted to its previous status (using the restore data option), then worked on at leisure to clarify and document all of the information needed.

On the other hand, I know that pre-1700 imports via GEDCOM can potentially cause some issues, but this is where the Merge process needs to be carefully reviewed by the PM's involved. I think the better solution to totally disallowing members from importing data is to try and do a better job at educating them.

So the correct process in this instance should have been to create Unmerged Matches, cleaned up the profiles, then performed the merge - instead of jumping straight to merging.

by Steven Harris G2G6 Pilot (518k points)
selected by Julie Ricketts
Indeed. I'm puzzled by this as well. Regardless - anything pre-1700 has been 'fenced off' or not …?
Members need to be pre-1700 certified to edit pre-1700 profiles, whether or not that is done manually or through the GEDCOMpare process.

In either case, nothing is really imported in this new process. Users have to create and edit profiles, they are just using GEDCOM data.

Quoting: "but this is where the Merge process needs to be carefully reviewed by the PM's involved. I think the better solution to totally disallowing members from importing data is to try and do a better job at educating them."

I agree. But then it should be officially recognised as a systemic failure. The System is not work here.

And then I refer you to the evidence on the page of this new member. Unaware and enthusiastic as he is (he is not to blame). So something else needs to happen.

And then I refer you to the evidence on the page of this new member. Unaware and enthusiastic as he is (he is not to blame). So something else needs to happen.

If a new member is making mistakes, and they will be hard to fix later, we already have a process in place to take care of that.

Which is obviously not working. Pre-1700?
To what purpose Steven? This is an never-ending circular issue. I do not have problems with members- even new and in-experienced ones. I have a problem with the system that does not take this issue seriously. I refer you to loads of other G2G questions on similar or the same issues. Of senseless duplication that undermines academic validation.
+4 votes
I know that the leadership discussed this in May, but, not sure that it is a high priority, or even a priority to accomplish.
by Robin Lee G2G6 Pilot (714k points)
Why not?
I mean the [human] integration & collation of data is essential to validating, or not? And this costs an immense amount of manual time. This labour is not [yet - we have by a long haul not yet accomplished with WikiTree the implementation of AI or even Big-Data instruments appropriately] automated.

Related questions

+3 votes
0 answers
+12 votes
1 answer
+10 votes
3 answers
+5 votes
2 answers
359 views asked Aug 29, 2018 in WikiTree Tech by Paul Conroy G2G Rookie (290 points)
+2 votes
1 answer
90 views asked Dec 3, 2017 in WikiTree Tech by Ron Everett G2G Rookie (250 points)

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...