Improvement Suggestion, Remove Find A Grave from the Suggestion Report.

Question

I propose that the Suggestion Reports no longer include any suggestions about Find A Grave. FAG is at best a poorly sourced site and by making suggestions about their data compared to ours is actually degrading the quality of our site. We are expected to do the research and then contact them to make the changes and that is a big waste of time, time that could be better spent on other improvements to our own work. Without those suggestions we would have far less damage done on WikiTree by well meaning Data Doctors who are not doing the proper research prior to making changes to WikiTree just to match FAG and remove the suggestion, changes that require time and research to undo properly.

I am not talking about any other suggestions at this time, just the Find A Grave suggestions.

Comments

"Just saying if there was a way to look at a certain profile for errors even if you were not the profile owner it would be helpful."

Jeanne, when you are on any profile particular profile, choosing suggestions under the drop down menu with their wikitree ID (e.g. Howell-4282) will give you an 8 generation report with generation 0 being the all errors on just that profile.  You don't have to be the profile manager to run the report.

An even more powerful way to do it is to use wikitree+ which allows you to narrow or broaden your error search in many different ways.  If you want errors on just 1 profile so you are not distracted by the errors on relatives, put in their ID, set generations to 0.

---

Jeanne, now we know where all the 571 errors are coming from. The citation is nice and I use it as well, but unless you change that first instance of www.findagrave.com just "FindaGrave" it causes a 571. Of course if you also used the template with "sameas=yes" it would ignore the citation and just compare the data.

There is a reason for the template. And if you don't use it, people complain about the errors. And if you do use it, people complain they have to use it.

---

Steven, are you saying the citation generated by Find A Grave is generating a "571 Link without a grave ID"?  For example, this would generate an error?:

• Find A Grave, database and images (https://www.findagrave.com : accessed 22 July 2018), memorial page for Rose Angela Casso Cochoit (8 Mar 1872–19 May 1936), Find A Grave Memorial no. 119239470, citing Catholic Cemetery, Fort Wayne, Allen County, Indiana, USA ; Maintained by Angela Cochoit Shoults (contributor 47627842) .

If so that's a problem on our part, not on wikitree or wikitree users.

---

I don't think that is what is causing the 571 errors. I am working on one of the pages now and out of 100 profiles only 3 have the actual memorial number. Those references is in the form www.findagrave.com, #123456789 for example. Most of the errors are of the type like this  

http://www.findagrave.com/cgi-bin/fg.cgi.Original data: Find A Grave.  With no number at all.

 I haven't seen any using the citation generated by FindaGrave in the suggestions I am working yet

---

Steven

Last winter Ales told me, to use in template, FindAGrave (F, A, & G in caps).

I have seen findagrave (no caps) and FindaGrave (F & G in caps) both working. I am guessing that Ales has the editbot set to accept any of the three.

Walt

---

Walt,

You're certainly right.

Due to my sloppy typing,  I have witnessed editbot cleaning up my FindAGrave capitalization problems.

---

Template it set to work in most common capitalisation variations. And EditBOT corrects them within a day to the correct one. 

I also recognise Memorial ID from FS citation, FAG citation, old url, new url and a few other common usages. 

A simple copy/paste of FAG citation doesn't copy the link, so you can't come to the memorial by one click. I do however recognize the memorial number and process the profile. The above citation pasted on WikiTree makes tekt like this without links:

Find A Grave, database and images (https://www.findagrave.com : accessed 22 July 2018), memorial page for Rose Angela Casso Cochoit (8 Mar 1872–19 May 1936), Find A Grave Memorial no. 119239470, citing Catholic Cemetery, Fort Wayne, Allen County, Indiana, USA ; Maintained by Angela Cochoit Shoults (contributor 47627842) .

So it is better to add FindAGrave template in it like

Find A Grave, database and images (https://www.findagrave.com : accessed 22 July 2018), memorial page for Rose Angela Casso Cochoit (8 Mar 1872–19 May 1936), {{FindAGrave|119239470}}, citing Catholic Cemetery, Fort Wayne, Allen County, Indiana, USA ; Maintained by Angela Cochoit Shoults (contributor 47627842) .

---

I usually insert the memorial link into FAG's source citation; their citation only has a link to their home page.

---

I don't actually use Find A Graves generated citations.  I find them a bit excessive.  But I know many others will so as long as it doesn't generate an error it's all good.

In my experience, all 571 errors come from ancestry.com which when linking a FAG reference to a fact automatically creates a citation which does not include an FAG memorial number.

---

so are you saying that Find A Grave, database and images (https://www.findagrave.com : accessed 22 July 2018), memorial page for Rose Angela Casso Cochoit (8 Mar 1872–19 May 1936), Find A Grave Memorial no. 119239470, citing Catholic Cemetery, Fort Wayne, Allen County, Indiana, USA ; Maintained by Angela Cochoit Shoults (contributor 47627842) 

will no longer cause a 571 error because of the findagrave link not followed by the memorial number?

Answer 1

I don't believe the report is suggesting that we make our data match theirs, nor that we are required to contact them to correct theirs either.

It is merely pointing out the inconsistencies for us to either correct (when necessary), or notate why.

Comments

Personally, if I don't have anything that will make the FAG date wrong I use it and mark it as approx/ uncertain with the button. That way a date IS there to help narrow down the search through research using the rootsearch app. It can always be changed later if you find something more accurate.

---

Darren, I think most of those No Date profiles are Fraziers that I adopted  for my One Name Study.  I adopt all U.S. Fraziers that are orphaned. I am happy for you to work on those if you like.  I have more projects than I can work on at one time.  I think a number may also be other family surnames I am working on and have adopted.  I may orphan a number of those just to simplify the number of profiles I work on.

Regardless, I work hard on my research and a lot of the profiles I manage are adopted, not created.  I'm typing on my phone right now, which is not as bad as my tablet in creating typos, but it is hard to read and type on. I will review your voluminous note when I have time.

---

Let's try and not make this personal,  everyone. Thanks! :)

---

Edie, I am in no way criticizing the profiles or your work.  I apologize if you took it that way.  There are literally millions of wikitree profiles which can be improved in data, detail and sourcing, including every profile I manage.

You used these profiles as examples of suggestions which you found to be a waste of time and annoying.  I am simply pointing out that in every case, the suggestion report was in fact useful for correcting and improving the wikitree profiles.  They turn out to be examples of why the FAG suggestions are important, and how they can be used to improve wikitree.

---

Edie I know the feeling of having too many projects for too little time. I haven't done pure sourcering for a while that wasn't related to some Data doctoring as well. I should also update the cemeteries I look after for that project.

I will try and look at your undated Fraziers and see if I can help find some dates. At the moment I am working on some suggestion 811 unclean merge profiles.

---

Joe, Ales had asked me about why I said that after correcting FAG errors the errors would pop up again. I posted those so he could see what I was talking about-- not for general review, argument, or critique. They were specific to his question.

---

Edie, Thanks for the profiles. I checked them and Suggestion report work as it is supposed to. I am sorry that you got so many replies on how you can improve the profiles. That was not my intention, but as Joe said, they are good examples of the value of comparing the data against cited sources.

As for suggestions reappearing, Only False error hides the suggestion forever. Here is the Status help page https://www.wikitree.com/wiki/Space:DBE_Status

and this is the explanation of the statuses. 

There are five actions:

• Comment (no change in status): This enables you to add a comment without changing the status.

• Not corrected: This sets the error as not corrected. It will continue to be shown in all lists.

• Corrected (hide until next recheck): This sets the error as corrected so it will be hidden from error reports until next dump. After that it will be shown again if it was not actually corrected.

• False error (hide forever): This sets the error as a false error. It will be hidden from WikiTree+ error reports forever.

• Proposed merge (hide for 30 days): This hides the error for 30 days thus giving a merge time to be completed. The error will be hidden from prepared error lists.

---

"I don't believe the report is suggesting that we make our data match theirs, nor that we are required to contact them to correct theirs either."

Does the suggestion say that?  Or does it just say there is an "ERROR?"

How are Wikitree members at large - especially those who don't frequent G2G - supposed to know that?

---

Thanks, Ales. I guess I thought once I "Corrected" the error, it would not pop up again. Hence, my frustration with this type of error. It might be helpful in forcing research, but most of my original data on the profiles was not "Incorrect", merely different.  For example, to use the birth year, when you do not yet have data for a more precise date, and marking it uncertain, is not incorrect.  The problem is when there is a more "precise" date on the FAG memorial without supporting evidence or a headstone. Using those dates is when we get into fiction such as we find on some Ancestry trees when it is not supported. I do research in my work for a living.  Putting dates without support on my profiles without support is fiction, until I find supporting data. Sometimes I will use a date on the memorial because I have nothing else, but I am aware it needs further research.  But that is what another person was arguing: that using FAG as true without supporting evidence elevates FAG as a source.  If that is what WikiTree intends, then that is what it is achieving with these errors.  Of course, these errors do help with typos.

---

Edie that's my concern, too.  FAGs without grave stone photos or sources to me are just leads. I do list them in the sources, but I don't put them in the data section unless I can confirm the info in another way. I have found too many FAGs that are simply wrong - sometimes even the wrong person entirely. This seems especially true of women who get maiden names attributed to them because a birth or death date is similar.

Answer 2

I second Dale's suggestion. I have had to start adding a Birth section to profiles where my research shows FAG is inaccurate in order to keep people from changing the dates to match FAG. If everyone used the "Suggestion" as a reminder to do more research that would be great. But to many people, it is a signal to automatically make the profile dates match FAG. Not a good move.

Comments

Shirley, I have taken to actually removing FAG as a source on profiles I manage. I have created a few using FAG as a source to make connections but I try to go back and find other sources so that I can remove the FAG citation ASAP.

---

Probably a good idea, Dale. I may have to start doing that as well. Unfortunately, well-meaning people keep adding FAG as a source.

---

...in order to keep people from changing...

but once the "error" is properly marked in the report, people won't "keep changing", because it'll be done, and no longer show up.

---

"false error (hide forever)" is a wonderful thing if used correctly. If used merely to hide an annoyance though, it can be harmful. Many FAG errors are caused by people using a spouse or child as reference for the profile. We actually have a template for that. Thus it would not be an error.

When systems are put in place to help combat false errors and people would rather just remove potential sources instead, we have a problem.

---

I include FAG links on profiles (those I manage or orphan), though in most cases I intend them as complements, to provide a link to further information, and not sources. Is it a bad thing now to add further links - not sources - to profiles? Isn't that what "see also" is for?

The FAG link is also in many cases, the principal source confirming the cemetery where the person was buried - so quite useful if you work with cemetery categories.

If the memorial is really poor, I don't link to it at all.

---

I replace FAG with other sources whenever possible. On a profile I worked on this morning the death record from the State had the burial date and cemetery name so adding FAG is not needed to have the data properly sourced. In that case I did not remove FAG, I just never added it because it would have been redundant. Finding better sources to replace FAG is better than adding it and then marking the resulting error false, that way you do not have false data as a source.

---

However this does not answer my question: are we allowed to add links to profiles that are not sources, or are we not? It we are not, then it should be clearly stated on standards & guidelines and help pages.

---

FAG is a source. It isn't a great source, it isn't a primary source. But it is still a source. If all the information was wrong then it wouldn't be a source. Of course in that case you probably have the wrong profile.

---

Playing devil's advicate: Ancestry.com is a source too.  Why no error report when wikitree profiles don't match ancestry profiles?

---

"Suggestions" software has no way to examine and compare profiles on ancestry.com since it is behind a paywall.

---

Is there a familysearch bot?  a Geni bot? a bot for all of the open sites?

---

No, there is not

---

Some could interpret this to mean that find a grave is a more legitimate source than ancestry or some other site.

---

The issue with checking those sites is that they would overload the suggestion report. The Suggestion report does check Wikidata which checks Wikipedia which is currently showing 23496 suggestions. 

Checking Family search would properly add an extra 2 million suggestions with Geni.com properly at 1 Million. Checking Ancestry.com would likely add 5 million suggestions. My heritage would likely be about 2 Million. Note all those figures are just my estimates but I do recall that Aleš Trtnik  was asked about adding other sites and the answer was that they would overload the suggestion reports. 

when you consider the top suggestion is no dates on profile with dates on relatives at 350 thousand adding these other potential suggestions doesn't make sense at this time. That isn't to say that new suggestions won't be added, (The No dates errors were just recently added) just that we as data Doctors need to reduce what suggestions we currently have. 

We currently have about 14% of profiles that have suggestions for them. I think that is enough for now. Plenty for the 519 Data doctors with Badges to work on with an average of 4700 suggestions per Data Doctor. Not every Data Doctor will be going Hard out correcting suggestions and the current top Data doctor has only cleared 591 so far this week. 

Answer 3

Is the problem the suggestion report or well meaning but misguided data doctors? Is there a similar issue with other suggestions? Based on recent discussions, there is a similar problem with Sourcers.

Is this really an education problem? Although you don’t have to have the Data Doctor badge to make a correction, perhaps you should have been a member for say 3 months to get the badge, with x number of non-GEDCOM contributions.

Apologies for hi jacking the thread.

Comments

The biggest problem is with the report. Most, if not all, would not even bother changing anything based on FAG data unless the report Suggested it. The best solution would be to not use FAG as a source, but that would be much harder than just removing the suggestion. No one has had an actual reason to keep that suggestion, just excuses for the changes made based on the suggestion.

---

Here’s a thought...

Errors 841 to 848 are valid

Errors 571 and 572 are probably valid as are 586, 587, 588

Errors 579, 581 maybe as they are location empty

The rest are the dates mismatch and cause the issues discussed.

---

Here's a thought, your error number list is not helpful to most. I have no idea what those numbers represent. My suggestion is to not compare our data to a site with poor at best quality at all.

---

Just this last weekend I found on one family I was working on errors on FAG for the LNAB, they do not use that at all, Birth dates, birth locations and relatives names. My data had birth records with parents names and locations recorded by the state and the family changed their surname to 3 variations over 4 generations, facts not reported be FAG.

---

A man goes to prison and the first night while he's laying in bed contemplating his situation, he hears someone yell out, "44!" Followed by laughter from the other prisoners.

He thought that was pretty odd, then he heard someone else yell out, "72!" Followed by even more laughter.

"What's going on?" he asked his cellmate.

"Well, we've all heard every joke so many times, we've given them each a number to make it easier."

"Oh," he says, "can I try?"

"Sure, go ahead."

So, he yells out "102!" and the place is dead quiet save for a few groans. Confused, he looks at his cellmate who is just shaking his head.

"Hey, what happened?"

"Well, some people just can't tell a joke."

---

LOL!!!

---

Error numbers from https://www.wikitree.com/wiki/Space:DD_Challenge_Find_a_Grave_IV#Error_List

Template
841 Template doesn't start with double {	13				2	9	2		12	11
842 Template doesn't end with double }	13			1		11	1		12	10
843 Missing template (spelling)	25				3	14	8		24	14
848 Error in template parameters

FindAGrave - Link without Grave ID	58629	419		341	4787	37056	16026		47859	187
572 FindAGrave - Linked grave not matching profile

FindAGrave - Multiple profiles link to same grave ID	1622	6	3	75	515	903	120		1569	132
586 FindAGrave - Link to merged Grave ID	43	14		2	1	17	9		9	7
587 FindAGrave - Link to nonexisting Grave ID

---

I think you missed a few at the bottoms and we have a spreadsheet for that.

https://tinyurl.com/weekchallenge

---

Steve - I was trying to point out the ones not related to the dates, but to other FAG suggestions. Throwing out some ideas that not all FAG suggestions are created equal.

---

Re: Is there a similar issue with other suggestions?

Yes, there is. Wikidata incorrect birth/death date. You can mark these errors as false, but if WikiData is corrected and later changed to the bad version once again, your error comes back (I have a recurring problem with a profile, I actually took the trouble to change Wikipedia and Wikidata - providing full details of birth record - and it was changed back to incorrect date - without removing the correct source! So this profile has a bold face paragraph explaining why the birth date is correct and Wikipedia/Wikidata are wrong).

Another issue with WikiData is when someone died recently. The date and place of death keeps changing for weeks until it is settled.

I would not advocate removing those errors however. They have helped me fix typos and look for additional info. The problem is not the report; it is eager contributors changing the data before checking facts.

---

Too bad there isn't one for "Nonexisting GRAVE."  As mentioned above, memorials for individuals born within the past hundred or two hundred years - those who have actual grave sites and headstones - are much more reliable than those created for obscure individuals born before 1800. Those memorials - which often skirt the guidelines by using "Burial unknown" and even linking to other "Burial unknowns"  -  give FindAGrave a bad name.

---

Exactly - a few contributors (a minority) seem to use Find A Grave as a repository for their own genealogy, rather than a place to share burial information.

Answer 4

The Issue with FindAGrave is that a lot of profile managers are using it as a source. It may be a bad source or it may be a great source. By having it as a source people are following Honor code point 8 

We cite sources. Without sources we can't objectively resolve conflicting information

Without checking for discrepancy then we would be falling afoul of Honor code point 2 

We care about accuracy. We're always aiming to improve upon our worldwide family tree and fix mistakes.

Yes mistakes and misunderstandings can happen. Yes there are better suggestions that can be done. Yes there are worse suggestions that can be done. 

I finish with a quote from the instructions for the FindAGrave suggestions. Just remember not everyone reads the instructions properly. 

This isn't mechanical, thoughtless work. This isn't like fixing typos. A genealogist needs to look at each one of these items and consider whether the information on Find A Grave is reliable. A lot of the information there isn't better than what we have here. Often it's worse. Just like on WikiTree, the information on Find A Grave all comes from its members.

Comments

If I don't have a date, I use the FAG date. If I have an Approximate, a before or after, I use the FAG if it fits in the time frame. If however I have a death certificate, I ignore the FAG date, mark it certain, and set the FAG as a false error.

Answer 5

I read all, what was written until now and I didn't read anything new. This was all discussed in the past.

I can give you some info on FindaGrave usage. In beginning of 2017 (march) when I started to do the error report for FindAGrave, there were 568.156 links to FindAGrave. Today we have 1.172.926 links to them, so the number doubled. Each week there is 10-15 thousand new links. 156.136 are done using a template. 

Here is the list of suggestions, so you will understand the numbers I am using in next comment.

• 571 FindAGrave - Link without Grave ID: This error indicates a wrong URL to Find-A-Grave.
• 572 FindAGrave - Link without matching Grave: This error indicates a wrong URL to Find-A-Grave.
• 573 FindAGrave - Empty birth date: This error indicates a mismatch between the WikiTree profile and the Find-A-Grave profile.
• 574 FindAGrave - Imprecise birth date: This error indicates a mismatch between the WikiTree profile and the Find-A-Grave profile.
• 575 FindAGrave - Different birth date: This error indicates a mismatch between theWikiTree profile and the Find-A-Grave profile.
• 576 FindAGrave - Empty death date: This error indicates a mismatch between the WikiTree profile and the Find-A-Grave profile.
• 577 FindAGrave - Imprecise death date: This error indicates a mismatch between the WikiTree profile and the Find-A-Grave profile.
• 578 FindAGrave - Different death date: This error indicates a mismatch between the WikiTree profile and the Find-A-Grave profile.
• 579 FindAGrave - Missing birth location: This error indicates a mismatch between the WikiTree profile and the Find-A-Grave profile.
• 581 FindAGrave - Missing death location: This error indicates a mismatch between the WikiTree profile and the Find-A-Grave profile.
• 585 FindAGrave - Multiple profiles link to same grave ID: This error indicates that two WikiTree profiles may need to be merged.
• 586 FindAGrave - Link to merged Grave ID: This error indicates that the link should be changed.
• 587 FindAGrave - Link to nonexisting Grave ID: This indicates an error.

All of the suggestions are improving wikitree. 

• 571, 572, 585, 586 and 587 are more technical indicating that link to FAG is problematic. After that actual comparison of data starts. 
• 573, 576, 579 and 581 are all indicating that there is some data on FAG, but none on WikiTree. 
• 574, 577 indicates, that there is more exact data on FAG. (1915 on wikitree and 6 Jun 1915 on FAG) 
• 575 and 578 are the only two, that can reduce the quality of data on Wikitree, but I doubt that any sourced date was changed due to this suggestion. If it was unsourced, then it is a big question on which one is correct. But I decided to keep this error, since it also points to the typos.

You can check the number of suggestions in last year here http://wikitree.sdms.si/default.htm?report=stat2

This are my comments on this thread and no down vote from me. 

BTW: All members that find the suggestions useful are working on FAG challenge this week. https://www.wikitree.com/g2g/644634/challenge-of-the-week-investigate-find-a-grave-suggestions and they tended 700 suggestions already. https://wikitree.sdms.si/Challenges/DataDoctorsChallenge/Suggestion.htm

Comments

My problem with FAG errors on the Suggestions report is that being OCD, I can't ignore it.   So I waste a lot of time trying to correct the report.  Sometimes the suggestion reappears after marking something a false error, so I have to do it again.  Or I have to contact FAG and the suggestion keeps showing up until FAG corrects their memorial.  

2 Main Points that bear repeating from others' posts:

1.  Anyone can check FAG and send corrections to FAG manager or make notations on a WikiTree profile.  We certainly do not need FAG errors on the suggestion report to make those improvements.

2.  Why are we spending so much time trying to fix FAG memorials or figuring out why WikiTree and FAG have different information?  I think that is time better spent just making WikiTree better.  I get tired of attempting to correct the Suggestion report numerous times for the same profile just because FAG has different, oftentimes incorrect or unsupported information.

---

I think that is time better spent just making WikiTree better.

and one small way of making WikiTree better is by comparing linked "sources" (FAG), to see if we have any errors. Often times, we do.

Answer 6

Sometimes Find A Grave is useful for finding links, dates, locations, CLUES.  It is no more sourced than a family tree, in my experience.  But for a research tool, can be helpful.  However, having it linked to the Suggestions report gives it greater credibility than I think it should have.  We should then link Ancestry trees, geni trees, etc, as they are usually sourced with the same degree of attention.  Anyone can find FAG on their own as a TOOL, and we don't need the suggestions report that might imply the data is better than something else.

Comments

"However, having it linked to the Suggestions report gives it greater credibility than I think it should have."

this

Answer 7

FAG is a source, a secondary source that may be good or bad, or, it could be a primary source based on the tombstone.

The problem is, once you start creating error reports, it can convey that one type of source is better (or worse) than another.

Comments

That would be a lot less feasible, technically, wouldn't it?
The Ancestry.com errors, I mean.

---

Probably so.

---

Actually, we have this tool.

https://apps.wikitree.com/apps/york1423/fs-match/

So FamilySearch might actually be a possibility in the future.

As far as Ancestry, we would have to pay to be able to check it. That sort of defeats the whole purpose behind WikiTree to remain free. We have enough trouble with the Ancestry debris we already have.

---

I can barely remember my computer password LOL.

---

Every source stands on it's own.  FAG is not even slightly equivalent to an unsourced personal tree on ancestry.com.  A FAG memorial with a photo of a gravestone is a primary source with the same accuracy and usability of a death certificate or a census record (both of which can contain errors).

---

I feel we always have to look at the underlying source, not the site that references it.

Answer 8

I strongly disagree with this suggestion, would rather see it expanded to additional off-WikiTree databases, such as other 'one world' trees like FamilySearch and Geni.  Certainly, suggestions should be accompanied with cautions, as mentioned by others, that the data may be unreliable and should be carefully reviewed, but that's true of ALL data sources.  If some are accepting FindAGrave information without question, then there's a need for more education, not a reason to cancel a useful service.

But more than that, I find it appalling that anyone would remove or replace a FindAGrave link!  That is a great disservice to the descendants of that person.  FindAGrave and/or BillionGraves pages are places where descendants can remember their ancestors, both recent and distant, and can feel a moment of their kinship, and leave a kind thought, a comment, and virtual flower.  I personally don't think a profile is complete without a FindAGrave/BillionGraves link!  Those who don't want such must be inclined toward the idea that profiles should only be dry sets of numbers and facts, reducing real people to being just numbers and data points, and that is really sad.  I really hope that others will find those profiles and restore those dry skeletons to real people, adding color and flesh to them - adding memories, pictures, stories, and links to their graves and memorials.

And the implication that FindAGrave pages and data are significantly inferior to WikiTree, is flatly wrong!

• I've done a lot of data correcting on FindAGrave, and I certainly agree there's a lot more to correct there, but I've also spent time correcting data on WikiTree, FamilySearch, Geni, and Ancestry, and while there are large differences between them, they ALL have terrible pages and profiles and unreliable data and unresponsive managers.  If you've done much searching on ANY of them, then you cannot argue with that.  I've also found that they ALL have some great pages and profiles and people.  The idea that WikiTree is better than everyone else sounds nice, is fine team loyalty, but is not supported by the facts.  It's OK to root for your home team, to feel that your team is the best, but it's not OK to look down your nose at all other teams, especially in genealogy.  WE ARE ALL FELLOW COLLABORATORS!  We have great people, they have great people, we have great profiles, they have great profiles, we have numerous profiles with issues, so do they.  It's not a fair comparison, because I've seen a lot more WikiTree data than FindAGrave data, but I have to say I've seen FAR more bad data on WikiTree than on FindAGrave.
• Like Ancestry (except for all the copying), some of the data on FindAGrave is added by relatives, and should therefore be treated as possibly 'primary' data, possibly more accurate than some of the 'official' records.  That's been my experience.  As someone else has said, FindAGrave pages are great for finding helpful clues - other relatives, other name variants, other dates, other related facts about the person.  I hurt when I see so much disrespect for FindAGrave pages here, and Ancestry trees and their users elsewhere.  Those people are our fellow collaborators, but are just starting out, with no knowledge of sources or the need to provide evidence for facts.  They are right where you were when you first started out, into this demanding world of genealogy.  But more than that, they all have primary knowledge of their close relatives, including those that have died.  They may have records that have been passed down, but don't yet know the value of those or how to use them.  The fact they need so much education doesn't make their data any less valuable.  I wrote a little article about this, "Looking for gems in the mud".
• Because some of the data on FindAGrave came from close relatives, or descendants with lots of records (but not necessarily any knowledge of sourcing), I have no doubt that when some here have chosen their data over the info on FindAGrave, they have made the wrong choice, at least some of the time.  Official records are not completely reliable.  My own father's birth certificate had 3 major errors, that made it really hard to locate - a mistake in his name, wrong day of birth, and horribly mangled mother's maiden name.  From the original, you could excuse 2 of those, but not the day of birth.  My great grandmother's death certificate, with my own grandmother as informant, has several serious errors.  Before you reject a conflict with FindAGrave info, review it very carefully with all other sources.

I'm fine with Aleš adding temporary per user options to not show selected suggestions, only because most of us have too much to do already, and have to be selective about what we work on.  But it seems anti-collaborative to consider it a waste of time to help improve profiles and pages wherever we find them.  Those who are working on those other pages are just as worthy of respect as anyone here, and so is their work.  They ARE our fellow collaborators!  Yes, you find problems dealing with some page managers, but WikiTree is no different.

Comments

Every day I see sooooooo many unsourced trees.  They have some BS "source" like "ancestry tree of Joe Schmoe," or "Linda's personal knowledge" for a profile from 1548.

Certainly, time would be better spent training the bot to spot all of these "junk" source profiles rather than quip about whether or not the FAG source has a link or not.

---

Yet the suggestion 571 Link without grave ID is such a Junk source.

So are the suggestions 802 empty profile and 803 nearly empty profile which help point out that there is likely no sources on those profiles

If you find profiles that don't have verifiable sources you can add the {{unsourced}} tag to the or use any of the Maintenance Categories to bring to peoples attention that a profile has something not right with it.

Answer 9

Sorry, I can’t agree.  When the errors were first released I had a similar reaction.  I was annoyed at a Find A Grave mistake, and overwhelmed by the number of new errors.  However, working with these errors has taught me the usefulness of FAG.

The accuracy and usability of FAG is very much dependent on the time period we are talking about.  For profiles of people who died within the last 100 years, it tends to be very accurate and very useful. They usually have a picture of the gravestone. The profiles are often created and sourced by near family members, and may be the only accurate source of data on a person.  For pre-1700 profiles the error rate is equivalent to ancestry.com.

Fact of the matter is, in my experience correcting errors, FAG has been vastly more accurate than wikitree.  Wikitree was created by the uploads of thousands of personal gedcoms.  The result is the vast number of accumulated errors from out of date sources, typos, guesses, estimates, incomplete data, etc. found on personal trees form the basis of wikitree.

Yes, I know you all have an anecdote where you are right and FAG was wrong.  These turn out to be a small minority of FAG suggestions.  Yes, I know Data Doctors make an occasional error by using incorrect data from FAG.  Frankly, the occasional mistake a Data Doctor makes is vastly out weighted by the thousands of corrections and improvements they make.  I might ask, why are you using a known inaccurate source?  Why do you not even bother noting the source you put on the profile is in error?

In cases where there is a conflict in the data and it turns out wikitree is correct, just mark it as a false suggestion and move on.  It is not complicated.

In time these errors will go away.  They will correct the errors in wikitree, or they will be marked as a false suggestion.  Wikitree is vastly better than it was 2 ½ years ago when I joined, in large part due to the efforts of the Database Errors Project.  Without it, wikitree would never rise above the garbage found in the LDS ancestral file, ancestry.com and geni.com.  Thank you Aleš.

Comments

I agree with Joe, and this comment describes my experience with the FindAGrave suggestion reports.

---

I also agree with Joe. The Database Error project has massively improved Wikitree. That is what is important. If by checking against a source that 1.1 million profiles use then that is worthwhile.

Yes other sites can also be checked against but let us fix the 14% of profiles that have suggestions first before we add more suggestions. Small steps are better than overwhelming big steps like checking against Familysearch or Ancestry.com.

Answer 10

In case you haven't noticed, it doesn't matter how many upvotes we give this, nor how many times we make this request.  Find a Grave "suggestions" are here to stay because the people in power like them.  Oh, well.

Comments

Unfortunately you're exactly right.  And it's even more disheartening that we're now having an organized activity to turn data doctors loose on these FAG discrepancies.  Back when the FAG comparisons were first implemented, there were many of the same disagreements and complaints voiced about it.  Those were dismissed with the declaration that we'll now call them suggestions, not errors, and a little pat on the derriere saying that you don't really have to do anything with the suggestions, or act on them, if you don't want to.  To now say that we'll just recruit other volunteers to work on them for you seems like a sort of "in your face" rub to further entrench this feature.

---

Last weeks challenge was Marriages. This week is FindAGrave. Next week it looks like the plan is Dates. There also seems to be an 8 week cycle through the various areas of suggestions. It wasn't planned to spite the people who don't like the suggestions. 

There are over 17 million profiles on Wikitree. There are about 14% of those profiles that have a suggestion.

There are about 1.1 million links from Wikitree to FindAGrave. There are about 20% of those links that have a suggestion. That suggests to me that the amount of suggestions on profiles are at nearly similar levels. 

Also even with the supposed focus on FindAGrave suggestions the Data Doctors have only actioned 1900 of those suggestions and 7400 suggestions overall this week.

---

I agree it's probably not time to eliminate the Find A Grave suggestions entirely,  but perhaps time to reduce the number of suggestions.   Stick to tracking the FindAGrave strengths of where and when the death occurred..... Avoid suggestions around the time of birth....

Answer 11

Much of this topic has been discussed repeatedly.  Many still view the 'suggestions' as an 'error report' in spite of the fact that the name was changed to emphasize that this is an optional feature of sorts.  Possibly what would be helpful to some is the ability to filter out certain events???

Comments

I previously asked about the possibility of adding such functionality to the Suggestions report - specifically to filter out the Findagrave suggestions:

https://www.wikitree.com/g2g/580033/enhanced-filtering-functionality-for-suggestions-report

Unfortunately, my post didn't get the attention of the intended audience, our tech team.

Perhaps Aleš will notice your answer, then notice my post, and finally give us his opinion of the feasibility of such functionality - the ability to filter multiple suggestions from the report.

I don't know if such functionality would alleviate the problems Dale has with the Findagrave suggestions, though.

edit: grammar edit

---

The question is which report do you filter.

If it is just to hide it from your view then it won't prevent other people from seeing the suggestions and maybe doing something about them.

If it is intended to hide them from everyone then then it won't happen. To do so would go against the Honor code as it would Reduce collaboration and Reduce accuracy. Any changes made to the suggestion report need to enhance the ideals of the Honor code not hinder them.

Yes some FindAGrave suggestions are false as the profile manager has sources proving a different data point than FindAGrave. In those cases you can put "False Error" and it will move off the suggestion lists within two weeks at the most. And before you complain about having to take time to do that, It is only doing research which makes the profile more accurate. Why would you not want to have a profile accurate if provided with something that suggests it may not be?

Yet there are more FindAGrave suggestions that are more accurate than what we have on Wikitree. Roderick John Finlayson (Finlayson-143) is such an example. Searching for the birth record as sourced on the New Zealand Births, Deaths, Marriage site would show that he is born in 1894 on December 2nd. He has generated a suggestion 575 different birth date error as the current Wikitree profile has 1895 as the birth year.

Answer 12

During last week's challenge, several folks used the Find a Grave suggestions to add death places to profiles I manage.

Thing is, while those places might well be correct (certainly at the county level, if not at the city), Find A Grave is not a definitive source for where the person died. (Unless someone's posted a death certificate on the FaG profile, and even then, the source is the death certificate.)

If they'd used the death places from FaG and marked them as "uncertain", I'd be OK with it, but they didn't even do that much.

How about if anyone who "fixes" a location error during a Find a Grave challenge doesn't get credit if they didn't also click "uncertain"?