Does everyone READ the comments and profile before leaving a Database Error message?

+46 votes
For everyone working the Database errrors:

Please read the profile and previous comments before leaving any comments or templates on a profile due to Database errors.   This project is starting to drive some of US nuts with the same message over and over.   If the profile says, the dates are being looked into or there is already a comment about dates not matching, please don't leave another message.   Some of these errors take a while to fix, please be patient with our profile managers that do not work on Wikitree on a daily basis.
in Policy and Style by Robin Lee G2G6 Pilot (875k points)
retagged by Dorothy Barry

Re Robin Lee you miss the point

The odd thing is that 

  1. he get married to two different ladies on the same day.... 
  2. with the same name 
  3. both profiles refers to the same source
  4. the 30 years old younger lady is said to get married at age 1 year...

The magic source that both use

  • Information from "Seek And Ye Shall Find: Pearson, Volume I Parson, Parsons, Peerson, Peirson, Person(s), Pierson" Compiled by Bettina Pearson Higdon (Mrs. Raymond Earl Higdon) October 5, 1

If the solution is merging or something else needs to be investigated.... and therefore we need feedback from someone with the magic source or the profile managers...
Compare Special:MergePerson

Big pic

Your reply with all it's intenstity with all due respect only supports (in my very humble opinion) the original relevance of the question. I have in the past (G2G-feeds) answered all the questions directly of indirectly that you are asking now.
I will work the issue, I cannot continue this.

I think that what Robin has asked for, that is, "Please read the profile and previous comments before leaving any comments or templates on a profile due to Database errors," is a simple request and it should be easy enough to implement. It is part of our wikitree policy to be courteous. Taking the time to read previous comments should be second nature in our collaborative atmosphere.

Every error doesn't have to be corrected "right this minute."

Here again, an example of why we should have the ability to "like" comments.  Or at least vote them up/down like answers.  :D

Indeed Anne & Summer :-)

Having a database of errors is an amazing tool. I'm not fighting the technology; like Robin I do though have reservations about the human element of / in it.

I just did a merge of Kruger-3328 into Kruger-2574 (Hilletje Levina Ethresia Kruger (1835 - 1892).) There are some issues with this profile that even a database of errors will not pick up on; only a human with some knowledge of the sources and the context can see that this profile is shaky on many grounds, and definitely needs further investigation (see the comment box and the footnotes [research notes]).

Robin, before you depart from this thread completely, would you be willing to share with us which types of error-fixing are frustrating you most?
Magnus, you need to drop and role. The tone of your responses here is inappropriate for someone with a Leader badge.
Thank you
Yes, thank you.  Wish I could "like" this one too.

4 Answers

+16 votes
Best answer
Thank you Robin and Philip for your comments on this issue. Your requests are wholly reasonable and aligned with wikitree's honor code. The db_errors project does work at a pace that is faster than any other project and we need to slow down. It is wholly reasonable to request that db_errors folks look for comments and information in the profile before making changes.

Magnus raises questions that should be handled in separate g2g threads -- and yeah they probably have been discussed already but are clearly not resolved-- when do we need a research notes section and where should it be placed? What are the pros/cons of retaining gedcom files as sources?

I think the problems and frustrations that Robin and Philip share might be more relevant to some error codes than others. (Which are the ones you're most frustrated with?)  I'm working on profiles that have NO data in their fields and more often than not are wholly disconnected from the tree. They're usually orphaned and certainly no evidence of project involvement-- direct or otherwise. But when there's an active profile manager I post a message. And so far it looks like only 50% of those respond. And 99% of the time I don't recognize those PMs.

In any case, thanks for sharing your frustrations and request.
by Jillaine Smith G2G6 Pilot (922k points)
selected by Robin Lee

Thank you Jan and Aleš I of course understand why these dates could look like a possible error and if you're correcting things on your own family member profiles it is no problem at all, but if profiles are part of a project it is something different, maybe we just need to make sure people are not correcting things for project profiles, but for those and profiles with active managers, just add a post telling what the possible error is (error template) and leave it up to the project members or managers to decide if this needs to be corrected or not ? 

And just heard the feed are not just duplicate feeds or reports, the db error is catching many duplicates and so is Matchbot, but there are some that are only found by db_error and missed by Match bot and vice versa , so we should keep both of course and... don't know if it's possible, could be a really dumb thought (no techy here :P) but isn't there a way to integrate the db_error into the matchbot where duplicates are concerned ?? Than we would have the best of both , but just one feed to check ... 

Chris is working on matchbot. I can provide him errors for matchbot, but I don't have access to private profiles. So matchbot can do better estimation than me. I can even tell him, how I calculate some duplicate errors, if he wants. You should talk to him about this.

Thanks Aleš , I'll show him this G2G and thanks for the great work, we all of course really appreciate everything you do here very very much . You just arrived and guess with this awesome and really huge project now hardly have some time left to work on your familytree eeh ? So a huge thank you from all of us !!

Here in Slovenia very little sources are available online, so one should go look into church archives manually. I called that field genealogy. So for last two centuries personal knowledge is quite good source, and before that internet trees (myheritage, geni, familysearch) are quite good source since someone went to church archives.

Indeed than you have to trust people actually went to the archives or do the field genealogy.  

You probably already found these but just in case familysearch links (scroll down and look in the 'purple' box) to online Slovenia records, maybe saves some of the field genealogy eeh :)

I have those and some more. They are collected on my slovene portal (in slovenian language)

Hahaha wauw you're a true magician ! 

I've added some categories to your Portal to make sure all people looking for Slovene help or sources can find it :)

And asked if Kitty could add the links to her (re) sources page Kitty's Library

Have a great weekend !

I agree, Aleš is a true magician.

Bea asked me to answer this: "Maybe it's possible to have just one feed/report for all catched duplicates (so the ones that db-error catches and the ones Matchbot catches integrated into just one feed?"

Let's see. MatchBot isn't a feed or report. It's a script that does searches and merge proposals. The merge proposals are then just stored in our merges and matches database like others. This database can then be used for feeds and reports, e.g. from Browse Matches as Rob Lenihan pointed out.

I think an integration would mean proposing whatever merges Aleš can catch. Maybe Corrections Officers are already doing this, or could do this?

If Aleš hasn't already (I can't keep up with everything he does) he could make a merge proposals easy with links like this:

Conceivably we could create a new bot account that automatically makes the merge proposals Aleš finds, or have the MatchBot account propose them. without a human reviewing them first. I think the latter is what Aleš suggests above.

If it goes on my to-do list it might sit there a while. We already have pending items to help empower Aleš that I think are a higher priority. Plus, if members are reviewing MatchBot's merge proposals after they're made anyway, why not have members reviewing these new ones and making the merge proposals themselves?

Hi, Chris,

I had in mind, that I would supply matchbot very likely matches (not all possible matches), that bot would check by its conditions, and then propose the match or not. Revalidation from bot should be done because i cannot see private profiles thus proposing questionable match. And bot would check my matches with high priority, since  they are very likely matches.

As I understood it makes 100 suggestions per day. But there was no mention of which 100, so I assume random ones. So bot could go through my list in a month and propose, mainly correct matches, and then back to old random suggestions.

For start I would just give you a list of profile pairs, that bot would analyse. We would then see the impact it had on my duplicates error lists, and repeat it on yearly or monthly bases or extend suggestion list.

I don't feel comfortable in making merge suggestions myself, since absence of private data could produce a lot of false merge suggestions. And it is not good for community to give it unnecessary work.

Regards, Aleš

The reason why I asked was because there was an increased amount of  bad merges, not only because Matchbot went a little nuts because it's now including all the variations of similar names, but also because everyone of course can and is using the db_error project link(s) and working so hard on correcting errors , but... also on proposing or performing and so on the merges catched by db-error project, so not only the more experienced, but also new members who understandably don't always know or understand exactly how merging should be done. 

So to try and prevent more of these bad merges, the Arborist project members are going to take care of the db_error duplicate reports( feeds, links or whatever we should name it ;)) and for the Matchbot proposals we now have the Matchbot Monitor Project .

If all the duplicates found by Ales's db_error project could somehow be integrated or yes maybe create a second  bot acount for those, I think it could help reduce the enormous workload for the Matchbot monitor project members and especially for the Arborists who now have to work on the ones the db_error project catches and on some of the more difficult ones the Matchbot already has proposed...and than we also still have merges that have to be looked at and sometimes taken care of that are proposed by all members . 

So if this job could be made more easy and less intensive or time consuming, we all I think would appreciate it very much ! 

And thanks for the quick response Chris and Aleš :)

+23 votes

Thank You for pointing this out Robin. I sometimes think that members of this and other projects think that we will just rush headlong into making changes without looking into sources to support our actions and even those of us who are on here every day don't see the emails about comments or even see the templates added because we are busy working on other things to improve the tree. It takes time to do accurate work.

by Dale Byers G2G Astronaut (1.7m points)
+21 votes
Thanks Robin

I'm also wondering lately about the priorities attached to some of these errors?  For instance with a profile that perhaps has no dates, or sources, or a biography, how urgent is it really to change the gender, or delete an obviously incorrect death place, and not try to improve the profile in other ways?

Don't get me wrong, I think the db errors project is doing great things in finding duplicates and correcting major errors, but if Wikitree is getting along fine with 300,000 profiles that don't have any nominated gender is it really that much of an error, that it takes priority over other improvements to Wikitree?
by John Atkinson G2G6 Pilot (630k points)
I agree John, Every error should be fixed but lets be smart about this and fix them with sourced information and not just change thing based on guesses or just making things fit the needed guidelines to remove the error. Doing things that way is probably why there are so many errors to start with. The project is moving in a positive direction so that is good.
What the db_errors project allows is for more people to contribute to the quality of wikitree who may not have the time or resources to do the deeper research we all know is needed. So I support people being able to, for example, fix the gender status without doing other research. That said, if changes db_errors folks are making are causing others to spend a lot of time fixing them (what kinds of errors are these?), then I concur that's a problem.
Jilliane, My biggest "Problem" of "Concern" with the project is that all to many times they are making changes based on assumptions and do not have any sources that say their assumptions are correct. If there is a source on the profile that supports the change or they add one that supports the change then I am fine with the change. It is the changes that have no sources to support them that I will reset to the old state until I, or someone else finds a source that makes the change reasonable.
Even the gender error should have sources. As an example in the lines I work on there are those named Francis or Frances. One is assumed to be male and the other is assumed to be female, but in my research I have found sourced data for both spellings being used for both genders.

Without sources we are just guessing and that can create other problems later.
Frances or Francis might be determined later at marriage, or other event. And sometimes all you have is a headstone that says, "Infant of ..." with no substantiating birth or death records. No name, nothing to denote gender. maybe one date, the year. Just "Infant".
+19 votes

On those profiles where I cannot be bold and fix the error myself (well sourced of course) I post a comment and I use the 'hide 30 days' function to avoid the error being reported again the next 4 weeks.

The profile manager can use that function too, so please don't put the blame entirely on the correction officers!


by Living Terink G2G6 Pilot (301k points)
In most cases, profile manager don't know about hide 30 days function, so the one who posts the message should hide it.
I question anyone other than the profile manager hiding the error because most managers do not even have the time I can spend on WikiTree and may not see the error. If you check and a message has been left then the profile manager will get an email and there is a date on the profile about when the message was left so the next person checking for errors can just wait 30 days and do the next step then. I know that the project wants all of the errors fixed quickly but quality work takes time. Where I used to work we had a saying "THIS IS A RUSH JOB SO SLOW DOWN, WE DO NOT HAVE TIME TO DO IT AGAIN."
Of course I don't just leave a message only saying something is wrong and then hide the error, leaving the profile manager at a loss as to what's up.

No, I explicitly say what error is reported, and when applicable also provide additional information like links to official sources.
The White Rabbit in 'Alice in Wonderland' had a corresponding saying: "The hurrier I go, the behinder I get." Not only do we need to spend sufficient time to do quality research, we sometimes need to step away and come back to it later. We may have a clearer head, or new sources are available.

Related questions

+37 votes
2 answers
+42 votes
10 answers
+13 votes
1 answer
335 views asked Jul 24, 2016 in The Tree House by Robin Lee G2G6 Pilot (875k points)
+9 votes
2 answers
119 views asked Jul 16, 2016 in WikiTree Tech by T Counce G2G6 Mach 7 (74.1k points)
+16 votes
0 answers
+21 votes
3 answers
+24 votes
3 answers
+21 votes
2 answers
+24 votes
4 answers
+23 votes
3 answers

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

disclaimer - terms - copyright