How to deal with "errors" that are not errors but can not be corrected.

Question

This profile and that of two of her children are causing an error  to appear based on the numbers that the program is reading. The mothers birth date is a date guess based on her parents birth dates and the children have a birth date using AFTER a date to prevent them from not being allowed to be OPEN. These profiles all fall into the dates where they could all still be living but to change the birth dates of the children to where they should be would lock those profiles down forcing the manager to keep them or to set them free first and then they could possible be deleted later. I do not think either option is a good one but because the profiles for the children are open someone could just make a change and then the manager would be stuck with them.

Comments

I was able to update the birth year of Bennett-238 

based on the information already provided.

From 1900 to 1960.

I apologize if I wasn't suppose to that. Please review what I did and edit accordingly. Initially the private status allowed me to edit. However since my edit that profile status has changed. I apologize if I offended anyone. I was editing from information already available in the biography in regard to d_b error questioned. 

 

 

 

---

Jerry, Yes that was the wrong thing to do. That date fit the after 1900 that was already there and while it removed the "error" there was never an error in the first place. Please slow down with this db_error project. Not everything should be "fixed".

---

If you know these people aren't living can't you just put in the correct birth date and mark "about/uncertain but non-living" and then their profile can stay open?

---

Jamie, The profile had an after date in it and that would say that they were born sometime after that date but before the profile was entered which had to be after WikiTree was started in I believe 2009. Add to that we are not sure that they are not living because based on the mothers estimated age they whould be younger than me.

---

Noted ..Thank You Dale .. It makes good service sense to customize and accommodate a variety of nourishing privacy objectives.  

This db_error process requires: continuation, to evolve, to adjust and to add best practices for all the customers WikiTree serves. 

 I believe that improvement is happening,(albeit slowly) and will further achieve the success of our WikiTree mission through our well meaning and intelligent collective efforts.  

Dale .. I think, you have made some other keen observations that are helpful towards our db_error progress. Your feedback, monitoring and problem solving, along with everyone else's are essential to this important effort. 

Always Appreciate your comments ..  

The Best To You and Your Family Tree.

BooDad 

 

---

Jerry, for future reference, here's our help page on Estimating Dates, just in case you haven't seen it :)

http://www.wikitree.com/wiki/Estimated_dates

---

Kool .. th'xs Eowyn Langholf ..

I didn't know about the Templates .. 

Great tool .... 

C'est Bon .. BooDad

 

P.S. Interesting example about New England colonies and typical marrying years. At the same time, (1700's -1800's) in Nouvelle France women often married at about 14-18 and men around 21.

Answer 1

You should be able to mark them as being "false" errors, Dale. I have had to use that on some naming issues that were coming up as erroneous. That said, we take privacy seriously, and if they may still be living, we probably need to make them private. I will take a look to see what we can do. They may fall within a project, which would be helpful.

Comments

My problem with your solution, Abby, is that just by having the error on the report others could "fix" them when by doing that they cause more trouble than needed because it was not an error the way it was.

---

no, when you mark it as a false error, then that fixes the error, and it no longer shows up on anyone else's report.

---

This is not the best answer because if the settings for the db_error project was set properly then it would have NOT set an error for someone who was born with the dates set the way they were as being an error. Privacy is important but if I set the date so that I can keep the profile more open to allow research but to release it later so that someone else wants it I should be allowed to. If I set the dates to exact dates without adopting then the profile becomes both Red privacy level and un adoptable, and possibly will be deleted in the future. Setting a false error for a profile that should not have been marked as an error in the first place only wastes my time and the time of others.

And Dennis that is what happened in this case by someone who was not on the trusted list for any of the profiles above because they thought they were helping.

---

I don't know Dale, the way you are doing sounds a lot like hacking our system, which we don't encourage. Hopefully others won't follow this example.

---

It's been my experience that a private profile cannot be orphaned.