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

Question

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.

Comments

Great point, Robin, thanks.

---

Thanks Robin (and Dale & the others) - it does take time to mend errors and some errors require a lot of research and re-thinking. At times easy to fix and at times not - but always taking time ...

---

Add a 
Research Notes section at the top of the profile that maybe help and explain status... and next step

 

---

Magnus, a reseonable suggestion but already being practiced - with so many profiles though just in one project alone, it is not a solution to the issue that Robin is adressing.

---

Dont follow you Phillip

The Database error project makes us work together more ==> we need to document and show why we do something and what we think should be done so other understands.....

• Do we have question marks then that should be in the Research Notes
• Do we have a To Do list that should also be in the Research Notes
• All changes problems error must be communicated.....

In Wikipedia people do that on talk pages. We have to find how to do it without talk pages and Research Notes is one way

---

In a project such as the one I'm working on the amount of profiles "under construction" at one or other point in time, consists of thousands. Unlike WikiPedia it is not only on 1 article, but on all the hundreds of different profiles waiting to be merged, profiles awaiting validation etc. Communication and collaboration enough. This of course has implications because of the amount of errors that may be prevalent. Having research notes is not a problem. Applying the concept of research notes to all the thousands of profiles merely to accomodate the error database because the correction officers do not read the comments, is not viable and only creates more work and a less efficiënt work flow.

---

I know "me too" comments aren't especially helpful, but "me too" to what Philip just said. If a comment could be selected as "Best Answer" I'd be clicking the star :D

---

Me three!!!

---

@Magnus. Case in point. You edited (quite rightly) the data fields of some South African profiles, today. However, even though they are not part of this project, these profiles do represent the children our COGH project covers.

You also edited the bio of http://www.wikitree.com/wiki/Van_Niekerk-995 which I then had to reset. We do not have research note pages, but we do have a system (see also [amongst other G2G feeds] this G2G feed) in place that unlike some other projects we see on WikiTree, try and observe some scholarly decorum in a collaborative fashion. This means that even GEDCOM data are not merely dismissed.

Who, what, where, when, why, and how. That's what allows proper collation and research. It would be impossible to work efiiciently in a way if one removes the GEDCOM data the way you did - even if double, it sitll contains information of value - (covering vast amount of profiles in an orderly, scholarly and validatory fashion and still stay ahead of all duplicates created - necessity is the master of invention - and in this case - our project - this has proved to be best practice).

I also corrected the places of birth and death. You did not pick up on that because you did not understand the context. South Africa did not exist in the nineteenth century as such.

It cost me around 1 hour or more just to "correct" the profiles after your "corrections". As I had to reset all the biographies you had "edit" - the { {Unsourced|South Africa} } could have stayed because it did not already have the { { Dutch_Cape_Colony} } that implies that there is a proces of validation (i.e. sourcing) taking place, but because I had to reset the bio's it also had to go ...

Magnus, I know that what you did was within WikiTree rules to a broad extent, but I would appreciate you (and all the others involved - me too - I also "correct errors" though I do not care for the bagde) to keep to the task at hand and do only what is neccessary and not create more work for others. Where I could I thanked you for your contributions.

---

Another example of moving too quickly and creating potential bad merge

http://www.wikitree.com/wiki/Pearson-1128

---

Philip I don't follow you at all if you don't add templates telling that this profile is inside project xxx so don't touch it then you will have problems. I suggest you define an error in the Database Error Project where you define what profiles are inside your project and check if those have categories/templates.... 

We can't guess....

Your comments
1) Gedcom information
The gedcom info is in the change log

Question 1-1 how do you use it? 

Question 1-2 when was it useful last.... the unsourced Swedish profiles I have seen that are from ancestry have no values in 99.9% of the tomes you click on them? 

Question 1-3 on profile Van_Niekerk-977 you have two entries to the same gedcom or?!?. Why? if you check the raw GEDCOM file see link the first source is after 12904 lines so 90% of the important profiles look unsourced

I fast look in it its 50 notes with some text on 888 imported profiles so its very very unsourced and I can see no extra value in the file compared what was imported.......

Question 1-4 if the gedcom is so important why don't we have a direct link to it?!!? or create a RAW Gedcom template {{Gedcom|gu_id=1830}} so its easier to access it 

2) These profiles do represent the children our COGH project covers

Question 2: How should someone outside the inner circle know?
Why don't you add a template? Research note or how do you communicate it? Should we assume if we have a profile outside Sweden that it's in a project and we can't touch it....;-)

3) As I had to reset all the biographies you had "edit" 

Question 3-1: Why reset? to get the gedcom text info that is in the log?!?! Why not just add a link to the log if that info is important or a note this unsourced profile was imported using a gedcom that can contain more sources....please see log or have a Gedcom template as I suggest above that creates a link to the RAW file 

4) Magnus, I know that what you did was within WikiTree rules to a broad extent...

I feel you invent your own rules and don't communicate them. I have been playing around for 2 years now on WikiTree and if you don't mark a profile or add a research note you will run into more problems...

M-1) Suggestion: define an error in the Project Database Error and check if a profile that fulfills your criteria to be part of the  COGH project and yadayda and miss a category xxxx then its an error 999....(my understanding is that categories maybe will appear in the dump in the future...)

---

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... 
 
http://www.wikitree.com/wiki/Pearson-1128
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.

Answer 1

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.

Comments

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) http://www.wikitree.com/wiki/Space:Slovenski_Portal_%28Slovene_Portal%29

---

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: http://www.wikitree.com/index.php?title=Special:MergePerson&user1_name=Clarkson-396&user2_name=Clarkson-634&action=compare

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š :)

Answer 2

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.

Answer 3

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?

Comments

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".

Answer 4

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!

 

Comments

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.