I don't know how to stop this, and the WikiTree community needs help.

+10 votes
303 views

I looked into the filing a Problems With Members, that doesn't fit. I looked into the requesting Mentoring help but that was either too complicated or just doesn't fit (not sure which), so I'm trying this route.

Here's the problem. Some records use the Julian Calendar Date, others use the Gregorian Calendar Date. In particular Find A Grave uses the Julian most of the time.

There is a relatively new member who insists on using the Gregorian Date and is changing the dates in the birth/death fields to match the Gregorian Dates, and he is leaving a note in the profile (some of them sound a little snarky to me, but that's me, and my interpretation of the notes being left isn't the issue...though the profiles I manage aren't the only ones these comments are being left in).

The problem is it's causing numerous 575 Find A Grave - Different birth date errors and some (don't know the code at the moment) Different date of death errors.  

I'm sure he has the best of intentions, but because we have had issues with previous communication (that's a long story), I'm not comfortable trying to explaining this to him.

The way I usually handle it is put the date that matches FindAGrave (when it's a Julian v Gregorian issue), and clearly state the date of birth i.e. So and So was born on 15 Jan 1742/43 in the biography.... if it's a major error I report to FAG. Maybe I'm doing it wrong...

Edit: Deleted my last two statements: Reason:

I was under the impression that the person was creating errors erroneously, however, in this discussion I have learned a couple of things. 

1. He's doing the right thing (some somewhat snarky comments in the bios aside). 

2. I had never seen the https://www.wikitree.com/wiki/Help:Date_Fields#Julian_vs._Gregorian_Calendar page before, and hadn't thought to look for it because I thought I understood how it worked, but I didn't. (I do now)

3. The errors showing up on the error reports are unavoidable. 

Knowing all of the above makes it a lot less irritating. 

Last thing...I thought about trying to figure out a way to delete this question, but in thinking about it (besides I don't think I could anyway), I realized a couple of things. A) Someone else might learn from this conversation. B) Eating humble pie once in a while is a good thingblush.

Thank you to Lindy, RJ Horace, Ben Buckner, and Herbert Tardy for teaching me something I should have known already. heart

in WikiTree Help by T Counce G2G6 Mach 7 (73.4k points)
edited by T Counce

Sounds like a Problem with Member to me, and might qualify as an emergency (Question #3).

Thank you for your discretion in not naming the other person involved. I see you have already tagged your question to the Mentors, so hopefully one of them should be along shortly to advise you.
Herbert, technically it's not as the error can be fixed at any point, I just go through my error reports rather frequently, so I see it more than everyone else might (maybe).

You should politely direct the new member to WikiTree's date guidelines:

https://www.wikitree.com/wiki/Help:Date_Fields#Julian_vs._Gregorian_Calendar

It may not help, but at least you will know he/she is aware of the preferred date format.

Beyond that, https://www.wikitree.com/wiki/Help:Problems_with_Members is a reasonable and appropriate action to take.

edit: misread your question, T. My bad!

edit 2: T, I believe that either you, the new member, or both have a misconception that Findagrave uses the Julian calendar for most of its date (I would certainly be surprised if that were their preferred calendar!).

I stand by my (and other members') advice that the Problems with Members process is the appropriate action to take to fix this misunderstanding.

They are following the guidelines...FindAGrave, however is not.
If Find a Grave gets it wrong, don't match it, just mark it as a false error.
Is that what the data doctors do?
Its what they should do :)
FAG almost always uses Gregorian. I doubt if most FAG contributors even know what the Julian calendar is. There is an official WT policy about it, which is more or less the standard in historiography.

https://www.wikitree.com/wiki/Space:Dates%2C_Calendars_and_Genealogy
BTW, don't confuse Julian/Gregorian with the date of the new year. Those are separate issues. In Anglo-American genealogy, we tend to assume Gregorian=Jan 1, Julian=Mar 25, because they were changed at the same time in England, but that's not always how it is.

Ben, I learned the last thing you said from the person's comments added to the profiles...that first thing you said is confusing sad

1 Answer

+7 votes
Shouldn't we where possible use Gregorian or rather New Style dates?  https://www.wikitree.com/wiki/Help:Date_Fields

 This is also conventional practice in historical writing,  my to go to example is that everyone learns that Charles 1 was executed in 1649 but the  date on the death warrant is 1648,

I rarely look at findagrave but for  buriasl in the period 1 Jan to 25 March pre 1752, I put the New Style date in the field and then clarify it in the bio using a double date. If a memorial is from the earlier period, then the same would apply. (and of course would apply much earlier for much of Europe)

If this causes a find a grave error perhaps it should be  marked as a false error.
by Helen Ford G2G6 Pilot (469k points)
What you say is true, however, as I said, I might be the one making the error, so I also need clarification. I personally do not understand why FindAGrave is used as a measure of accuracy on dates since many of the memorials are not sourced, and just about as many do not have tombstone photos to verify with.
What I do know is that before a few months ago these errors didn't exist and now they do.
FindaGrave is not the standard of accuracy for anything, for exactly the reason you stated, T.  There has been a lot of discussion about the FaG Suggestions falsely leading people to 'correct' accurate profiles by making them match FaG.  The clarification you seek is in the Help link Lindy Jones provided in her comment above.
I read what it said at the link that Lindy provided, which basically said I'm doing it wrong, so in the mean time, while I go back and fix all the ones that the person created by creating my error, I'm wondering...does the error show up immediately after the correction is made by the other person or does it take a while? (If it shows up right away, they could could mark it a false error then, so it doesn't sit on the error report until a data doctor can get to it, or someone else looks at their report...I've spent hours this week going through these errors when I have other stuff I need to do, too).
The error report ('Suggestions') is only updated once a week, on Monday afternoons in US timezones.  Corrected and new errors don't show up until the next update posts.
So the answer is, no there is not a way to stop this...thanks Herbert.
I may have a little bit different take on the Find A Grave scenario.  I likely submit a dozen suggested edits to various memorial caretakers per week.  Most are happy to see the research posted on the WT profile and update the material on FAG.  Several memorials on FAG are no more than hyperbola; though, being optimistic, I hope they will attract other contributors to upload images, obits, tombstone images, and connect family using cemetery records.  Hopefully, the more people that research various venues can find the truth for us all to share!

Related questions

+7 votes
1 answer
196 views asked Jul 24, 2018 in WikiTree Help by C. Mackinnon G2G6 Pilot (334k points)
+9 votes
2 answers
214 views asked Oct 11, 2023 in The Tree House by Jo Gill G2G6 Pilot (166k points)
+4 votes
1 answer
+5 votes
1 answer
276 views asked Nov 24, 2020 in WikiTree Tech by Cindy Cooper G2G6 Pilot (328k points)
+2 votes
1 answer
+3 votes
2 answers
+5 votes
1 answer
222 views asked Jul 31, 2018 in WikiTree Tech by Judy Bramlage G2G6 Pilot (212k points)
+20 votes
2 answers
0 votes
2 answers
+7 votes
4 answers

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

disclaimer - terms - copyright

...