Suggestions News and Updates (June 18th 2023) [closed]

+13 votes
661 views

News

  • Continued rescan of the external links, that were ok in initiall scan.
  • Changed some internal database structures to take advantage of the new server to improve performance. If you notice some strange behaviour please let me know.
  • Added operator relation=... to the search. This is kind of an operator that performs relation on the profiles on the left side of the operator. Magic Words: father, mother, parents, spouses, children, siblings, nuclear replace the result with the relatives. If you want to retain the starting profiles in the results, you can use the same relations with the add prefix (addfather, addmother, addparents, addspouses, addchildren, addsiblings, addnuclear). The relation is limited to 100000 profiles. That means that the query on the left side must have less than 100K profiles. Examples:
    • Tudor-18 relation=children
    • Tudor-18 relation=parents relation=parents
    • Trtnik-4 relation=nuclear relation=nuclear relation=nuclear
    • Trtnik-4 relation=addnuclear relation=addnuclear relation=addnuclear
    • Puritan_Great_Migration relation=children Country="United States" Not Puritan_Great_Migration Not birthCountry="United States"
    • unconnected england 17cen male relation=spouses france female
    • b1730 england relation=spouses france
  • Wrote some more help on search execution order. See Help:WikiTree_Plus#Search_priority
  • Added SearchLog: at the bottom of the search results, where you can see some numbers in complex queries.

Previous News

Challenge

https://www.wikitree.com/g2g/1595280/challenge-of-the-week-improve-star-profiles

closed with the note: Outdated
in The Tree House by Aleš Trtnik G2G6 Pilot (878k points)
closed by Aleš Trtnik
Aleš, do you have statistics on the outcome of suggestions, overall and/or broken down by error number?

A useful performance indicator for WikiTree Plus would be a low fraction of false suggestions. Useful indicators for WikiTreers would be a high proportion of fixed suggestions, and a low proportion of ignored ones.
I do have such numbers, but they are more for my assesment of the suggestions.

Here you can see the stats I keep on suggestions. https://plus.wikitree.com/default.htm?report=stat2
Just wanted to say "Thank you" for the new relation operator.  I'm finding it very useful.
Sorry if I'm missing it, Aleš, but I'm not seeing where those statistics graphs are showing what percentage of a given suggestion have been marked fixed or false, or have not been addressed.
Jim, relations between fixed and false is not in the graphs. I do have that raw data, but it is not really chartable. Also a lot of suggestions get corrected without setting a status.
Thanks for the reply, Aleš. I can see that fixes are transient and not necessarily documented, so hard to track. However, can't the percentage of suggestions marked false for each DBE number be made available? If that is high in a particular case, it may indicate the code generating that suggestion could be tuned. (A table would be fine: no need for a graph.)

I raise this because I had to deal with 20 suggestions last night, 19 of which were false.
I preparred the summary you wanted.

https://www.softdata.si/wt/SuggestionStatus.htm

There were 5,283,994 statuses set.
Thank you, Aleš, that looks useful. I'll study it.
Looking only at the 811 Uncleaned profile after merge, it shows how many people mark them as false or not corrected when profiles obviously have to have multiple biography or sources lines and they just don’t want to clean up the profiles.

People don’t understand when the Not Corrected should be used.

I've retabulated Aleš's statistics at a space page, DBE suggestion outcomes, which allows sorting of the results by percentage of a given status. So far I've looked at three:

  • 572 FindAGrave - Linked grave not matching profile. Many of these cases need the FindAGrave template parameter sameas=no, which may only have been introduced since the suggestions were marked false.
  • 403 Single sex marriage. Quite a number of these suggestions are false, and this fraction may increase over time. Others do result in correction of sex of one spouse.
  • 420 Unmarried parents with other marriages. 53% false, only 18% corrected. This suggestion may be more trouble than it's worth :-)

If people are making mistakes, it is surely unintentional. But Linda is right in so far as more education may be needed in some aspects of this complicated system.

Suggestions 403 and 420 are expected to have certain number of false suggestions, since there are cases where they are actually ok. But computers can't know that.

FG suggestions are ofte marked as false without even looking at it. Some people do that and we can't do anything about it. The only thing we can do is to check the Hidden column in the report.

I prepared another report https://www.softdata.si/wt/SuggestionStatus1.htm that splits the numbers in 2 groups. the ones that no longer have a suggestion and the ones that still have the suggestion.

I think it will slightly adjust the numbers, but the ones you noted will probably still stand out.

1 Answer

+3 votes
Many people will set Wikidata, FindAGrave, and Profile Completeness to False because they don't understand them, don't want to be bothered by them, or don't know how to change them.

I have corrected plenty of Find A Grave for merged or non matching Find A Grave suggestions set to False.

No matter how clear information is in Suggestion pages, too many people would not see changes because they don't look at them because they 'think' they are doing it correctly with the False suggestions.

The 965 and 966 suggestions for bad links has many of our Projects swamped with time to correct those profiles. Some of those are being set to False with a note in Bio that link is bad, but being left in bio in case someone can find a good link for it.
by Linda Peterson G2G6 Pilot (877k points)
I’ve seen bad links marked false with reason given as “Not a close relative. Not going to bother.”

To which I wondered, why bother being profile manager then?

In your example above, I guess it’s a better than deleting it without trying to fix it, which I’d be positive some people are doing.
All that is needed to those is the template with 'same as=no' used in the 3rd parameter, but people don't take the time to look at the help page to see, that is how to fix it correctly to avoid suggestions. I have also seen plenty of those that actually have the profile person's grave. If they would revisit the page.

Unfortunately many also say for many suggestions  'I didn't do it, so I am not going to fix it!'

Unfortunately the people that updated profiles they are not PM of, don't see the suggestions the following week, but if someone doesn't understand the suggestion or what was done, they could send a message to the editor.

The Help page section Linda mentions for the FindAGrave template sameas=no parameter is at this link.

Since you can't use sameas=no if the person is the same, I keep a list of profiles I don't manage I've recently edited in a way likely to cause a false Find a Grave suggestion, then try to remember to check and mark them false each week. However, it's not very predictable: some that I expect to give suggestions don't.

Related questions

+10 votes
0 answers
+9 votes
0 answers
+21 votes
1 answer
+19 votes
3 answers
+15 votes
1 answer
+18 votes
0 answers
+19 votes
2 answers
+19 votes
2 answers
+9 votes
1 answer
+16 votes
1 answer

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

disclaimer - terms - copyright

...