Please do NOT delete data when completing merges

Question

Today I have had to restore the part of several profiles that had the X was born in xxxx, he was the son of [[Blah-1234| John Blah]] and [[Anothername-3456| Joan Anothername]] because the person who merged the profiles just completely removed the second set of info without taking out the data and putting it under the first Bio heading. They did however leave the autogenerated "this biography was autogenerated and blah blah blah" plus some gedcom waffle for me to clean up.

How difficult is it to NOT REMOVE ANY DATA?
Please do not complete merges that other people are in the process of trying to achieve in a top down order, if you don't intend to do it properly and carefully. This is not a race.

Comments

I do remove, though, data pertaining to parents and/or children of the profile in question that have been imported in typical Ancestry or FamilySearch fashion when those parents or children have their own profiles and are documented there.

---

Please don't remove the names of a person's parents or lists of that person's children from the biography section of a profile. These are details of a person's biography that should be documented and supported by source citations in the text of the biography.

Even when these details aren't supported by good sources, it's useful to have the information. It is inconvenient for a reader to have to click individually on the names of children to find their life dates; it is much easier to see the story of a couple's family when all the names and birth dates are in the profile text. And when connections between profiles are lost or altered (for example, when an extra child gets connected by mistake), the information in the biography is very helpful for reconstructing the intended family relationships.

---

I'm not removing parents or children's names. If I have documentation for birth, marriage, and death for the person in the profile AND I have the same documentation on the parents' profiles I may on occasion remove the source for the marriage of the parents since I believe that the typical presentation of that information in a GEDCOM import from Ancestry is more confusing than helpful.

See Sylvester Bayer:

1. ↑ Státní oblastní archiv v Třeboni, Parish Register Rychnov u Nových Hradů, Book 1, page 127, image 73
2. ↑ Státní oblastní archiv v Třeboni, Parish Register Rudolfov, Book 3, page 14, image 130
3. ↑ Státní oblastní archiv v Třeboni, Parish Register Rudolfov, Book 12, page 70, image 50

vs.

1. ↑ Bayer-336 was created by Alfred Fischer through the import of Alfred Fischer_2015-02-20.ged on Feb 20, 2015. This comment and citation can be deleted after the biography has been edited and primary sources are included.
2. ↑ Source: #S65 Page: Aufnahme 33 Data: Text: 10.2.1757 CONT Pridie natum ex Patre Sylvestro Bayr inquilins Rudolphstadiensi, et uxore Susanna Conjugibus, cum inquisitum est nomen Mathias CONT Patrini levant fuit Adalbert Weys civis et l*arius Rudolphstadiensis, * fuit Rosalia uxor Francisci Schwartz civis et * Rudolphstadiensis
3. ↑ Source: #S65 FOOT Trauungsbuch Sylvester Bayer 1749, http://digi.ceskearchivy.cz/de/6999/130.
4. ↑ Source: #S192 Page: 50L5 Data: Text: 21.2.1808 CONT Rudolfstadt 50 CONT Sylvester Bayer, Bürger und Inwohner CONT 98 Jahre CONT Altershalber
5. ↑ Source: #S193 Data: Text: 5.10.1790 CONT Silvester Bayer Witwer 66 Jahre CONT Maria Anna Tochter des verstorb. Joseph Pock aus Rudolphstadt 40 Jahre CONT Zeugen Martin Prückl und Andreas Bauer FOOT Trauungsbuch Bayer Silvester 1790, http://digi.ceskearchivy.cz/de/7006/6, 5.10.1790 Silvester Bayer Witwer 66 Jahre Maria Anna Tochter des verstorb. Joseph Pock aus Rudolphstadt 40 Jahre Zeugen Martin Prückl und Andreas Bauer.
6. ↑ Source: #S192 Page: 50L5 Data: Text: 21.2.1808 CONT Rudolfstadt 50 CONT Sylvester Bayer, Bürger und Inwohner CONT 98 Jahre CONT Altershalber
7. ↑ Source: #S65 FOOT Trauungsbuch Sylvester Bayer 1749, http://digi.ceskearchivy.cz/de/6999/130.
8. ↑ Source: #S193 Data: Text: 5.10.1790 CONT Silvester Bayer Witwer 66 Jahre CONT Maria Anna Tochter des verstorb. Joseph Pock aus Rudolphstadt 40 Jahre CONT Zeugen Martin Prückl und Andreas Bauer FOOT Trauungsbuch Bayer Silvester 1790, http://digi.ceskearchivy.cz/de/7006/6, 5.10.1790 Silvester Bayer Witwer 66 Jahre Maria Anna Tochter des verstorb. Joseph Pock aus Rudolphstadt 40 Jahre Zeugen Martin Prückl und Andreas Bauer.
9. Source: S192 Title: Rudolfov 12 Tod 1784 - 1830

• Source: S193 Title: Rudolfov 10 Trauungen 1785 - 1863
• Source: S65 Title: Rudolfov 3 GTS 1738 - 1784 Repository: #R55
• Repository: R55 Name: http://digi.ceskearchivy.cz/de/6999/234 Address: E-Mail Address: Phone Number:

In this example it's not parental information but I think one can see how unclear the source section from this particular GEDCOM import looks.

 

 

---

Yes, the parents' marriage data that often gets inserted via Gedcoms should be removed (or moved to the parents' profiles, if it's not also there).

I commented as I did because I do sometimes see members deliberately deleting parents' names and lists of children on the grounds that the profiles of the parents and children are linked to the profile.

---

Hi Ellen

A while ago I watched Julie Ricketts' video on how to clean up a GEDCOM biography. On that she does delete names and lists of children on the grounds that the profiles of the children are linked to the profile.

https://www.youtube.com/watch?v=7gJMhj-93fw - see time 15m20s

I always kept the info but started deleting it after watching the video, but I do agree that it might be better to leave as much information on a profile as possible

---

I also concur that deleting the family information from the narrative should NOT be recommended; sorry to see that in the video. Unless and until Wikitree allows source citation on data fields, placing the list of children and the marriage info in the narrative is the only place to cite our sources for that information.

 

---

Yes, anything in the data field -- including links to children, is derivative, and it is pure fiction unless it reflects a documented list of children in the biography.  I'm sorry that there is a video saying to take the list out -- that's tantamount to promoting vandalism.

Answer 1

You can remove repeated data, though, but after a careful comparison.

Comments

But do note that it is not repetition when the same fact appears in the profile data section and in the biography.

---

I meant things like 2 copies of the same census doc, 2 sets of the same death record, etc.

Answer 2

I think one of the biggest weaknesses on Wikitree is that early on, new members push buttons and in the process make a mess of things like merges. Their mistakes are not intentional and they may have no idea that this forum even exists.

Answer 3

Hi, I suggest that if profiles are being actively worked on by someone, and that person is making a merger request in connection with that work, they should include a clear instruction requesting no data deletion in both the merger request AND in the biography section so that it is very obvious that the profiles are undergoing significant re-work.

We do want people to delete data from merged profiles if it is obvious "GEDCOM junk" etc, especially if they are project managers of  profiles that have just been merged.   Clean-up of merged profiles is really key - this is one of the reasons for the Arborist project.  

Data should be deleted thoughtfully, however - if members are not comfortable in how to do that, then do not delete information.  Ideally all members would get up to speed on how to delete (erroneous) data from their profiles, especially if it is the GEDCOM junk.

Answer 4

None of the above are really like the situation I was outlining, though I appreciate the examples, so that others can learn. The other (active) manager and I were unable to complete the merges any sooner, because I had to make an unresponsive manager request at the top of the merge stack, where sources were thin on the ground. The minute that got orphaned, so were the rest of the branch and once I had adopted the profiles, I started doing the merges but one has to sleep sometime and when I came back they had already been done, which I was initially grateful for, until I realised data was missing. I really felt that keeping the gedcom junk  (user number, date changed etc) and losing the albeit brief bio on some of the profiles (as provided by the active manager), with birth date and links to the parents was a retrograde step. If the parents get disconnected, like they occasionally do by people who are not really sure what's what, then you have something that tells you what's been disconnected.

At the end of the day, we shouldn't be removing data just because it has not got a source, we should be searching for then providing a source if one is available, before considering any deletions of data. I work very hard at trying to find sources for the profiles I come across that have no real sources and I don't see why that should not be the standard to aim for. If you don't have the time, then leave it as it is. I have worked on this particular family of emigrants with one of the  profile managers since last October and before that was working on the same family name in England trying to establish a connection between Warwickshire branches and Oxfordshire branches. Removing information hinders that process.

Comments

In such case of data deleted through merger, is that data lost forever, or does it reside in the changes tab record?

---

These particular ones were in the changes but it creates work to have to restore a profile, and that is only possible if you are savvy enough to check what has been edited out. My whole point is, this should not be happening/necessary.

---

Just wondering. ..I know that there is a request for people to complete merges, and there are people who actively search for merges to complete. Is this really helpful? Someone had to request that merge, so apparently someone is interested in completing it. Should we really have floaters going around completing merges they don't have any interest in? And then either leaving a mess or deleting info that needs to be in there?

---

Edie, that is an interesting question:  

 Should we really have floaters going around completing merges they don't have any interest in?

I appreciate the second set of eyes on merges I propose, especially when I propose merges on lines/regions I don't know much about.  

Ideally a profile manager or surname researcher or badged Arborist does that work but it seems obvious that there isn't anywhere near enough profile management expertise volunteering to keep up with the merging work generated by the WT userbase.

So we appear to be incentivizing volunteers to fly through those lists of pending merges and 811 database suggestions (merge cleanup needed) by awarding contribution points to them for doing it.  On the whole, the work gets done in a more timely way and profiles are more accessible to newcomers who are checking out the site.  But there is a noticeable cost in data loss and in already-scarce PM/Arborist time needed to restore that data.

I started writing this comment thinking I was going to ask for the "floaters" incentives to be dialed down but as I have thought through it in writing I'm not so sure.  

In conclusion: It's complicated.

---

I think the key is reading G2G and keeping up with changes, suggestions,  standards and styles. Some people think G2G is about gaining points, but I find that it is really important to keep up with what we are doing as a group or as a whole. People who don't are more likely to make unintentional errors... which then have to be fixed.