create a " button" indicating that I reject the hypothesis
I have find that some people is not my relatives. I suggest a button that rejects the hypothesis.
I also suggest that you create a column next to your hypothesis so that it is possible to correct the error and enter the correct data.
It would make it easier as it would otherwise be frustrating to follow the information that is incorrectly entered into the genealogy data.
Today I found that Martha Larsson born 1787 and Olena Henriksson born 1818 are included as relatives. which is wrong. Desideria Hansdotter´s mother is Helena Johansdotter born 29/12 1829 in Lyse, Sweden-died 9/12 1891. Helenas mother was Dorotea (Dordi) Olsdotter born 1796- died1865 in Lyse , Sweden.
It helps if you can arrange this, otherwise it is pointless to read the hypotheses.
Best regards
Siv Pettersson
Comments
-
If they are "included as relatives" in Family Tree, you can detach any incorrect relationships yourself. When doing so, add evidence (in the form of a reason statement) and also add any sources / records to confirm correct relationships, which you can also add. If you are referring to finding the information elsewhere, please provide a screenshot or a URL linking to the page in question.
2 -
Great minds think alike. I agree not only should there be the option to change relations - which already does exist (for open-edit profiles) - but there also needs to be a residual rejection of an incorrect hypothesis/relation and a residual accept of a 'correct' one. This is the topic of an Idea I put forward last week. Further, there should be the same residual accept/reject in collaboration with Family Groups - such that - the accept/reject tallies on each profile artifact/element are visible to any profile peruser.
0 -
There is no "Hypothesis" section on FamilySearch, so I'm not 100% certain I understand what you're saying. Correct me if I'm wrong, but I think what you're asking for is a button that makes it so information can no longer be changed?
This would be a good idea, if you could be certain that it would always be used correctly. However, there are people who would probably add a common misconception and then lock it into that, meaning the only way to fix it would be to completely disconnect the person from the tree completely and put a duplicate person page in their place, making it even harder to fix errors. (For example, there were three Thomas Graves' in Massachusetts in the late 1500s, but there are people who would gladly put the information of another Thomas Graves and then lock it, because there were several genealogy books that mistakenly combined them.)
There is another possible interpretation of what you said that I thought of, and that is a button that makes it so that specific information will be automatically rejected--for example, making it so that a birth date cannot be set to 1846. The problem with this is obvious: what if you were wrong, and the person who entered that date was right?
Clearly, the ability to change the person page is essential, even if it means errors will sometimes creep in.
Here are some solutions that already exist in FamilySearch:
♦ When you make any change, add a detailed reason statement explaining why you made the change you did. This is available no matter what you are changing
♦ If a mistake is being made too often, add an Alert Note to explain the problem
♦ If there was an incorrect merge, you can unmerge them from the recent changes page
♦ If you are worried about a person being incorrectly changed, follow that person so that you get notified about any changes that are made
0 -
The hypothesis section is obscured - but yes, there had to be a hypothesis behind a relationship attachment - whatever it was.
The problem with leaving it open-edit even with noting a reason for changing, etc - is that it can be changed right back. If 'My Tree' already contains all my carefully researched assertions, plus the collaborative acceptance of an entire Family Group (I don't know - say 200 people in the group) - if there were the capability of exposing this collaborative acceptance to the person making a change and the harm their change could/did do - then maybe it would at least promote more collaborative interaction. In my experience - if there is going to be an 'edit war' - people will avoid collaborating and just change what they want to change. That is fine except when incorrect. If a change has no appreciable/vital effect on a profile then no need to interact... Only when change does make vital profile difference - I think this would be a good Idea (such as Siv's issue here). But additionally there also needs to be rejection of the merge/addition that was incorrect.
I am not going to investigate Siv's tree - I just take at face value he knows his tree well enough to make the assertions he is making. Family Tree obscures Siv's tree/research with everybody else who may have also contributed to the profiles concerned. My Idea basically - allow Siv to work in 'His Tree' (personal tree contextual login) do his careful research, gain collaborative acceptance of all profile artifacts/elements (acceptance indicated by thumbs up tally, rejection indicated by thumbs down, provisional indicated by box with question mark or maybe clock). If Siv has a whole Family Group accepting his assertions - especially I don't know ... looks like he's about 6-10 generations back - then that should be exposed to the user wanting to make a change and give them pause to proceeding with a change - especially if their relation to the profile is more distant.
Plus a whole Family Group in agreement Following a profile means it will be easier/more likely that someone will be able to change the profile back sooner than if there are a couple people following... So I am not saying change the open-edit structure (though I would like to mark profiles I am certain of read-only) - I'm just trying to prevent bad changes and make it easier to Restore/revert them if they do occur (something which is lacking in Family Tree - my opinion).
Here are some solutions that already exist in FamilySearch:
♦ When you make any change, add a detailed reason statement explaining why you made the change you did. This is available no matter what you are changing
♦ If a mistake is being made too often, add an Alert Note to explain the problem
♦ If there was an incorrect merge, you can unmerge them from the recent changes page
♦ If you are worried about a person being incorrectly changed, follow that person so that you get notified about any changes that are made
Here are some problems with these solutions that already exist in Family Tree:
♦ A detailed reason statement is not a requirement for another user to read. If you are going to spend extra time typing up a detailed reason/conclusion - I should hope there would be a method to prevent/impede the change from reoccurring.
♦An Alert Note is not a requirement for a user to not make a change. An Alert Note can be deleted by anyone. It is just a speed bump if one even pays attention to it.
♦Yes, Unmerge is only available if there have been no subsequent changes - which is very rare in my experience. Most relationship changes involve several line items/relationships which then make Unmerging unavailable. Restore may be available but you possibly may lose some intermediate data. Unmerge also may not revert all relationship/data changes (unsure since it is so rare) - you would still have to continue investigating all the changes and revert each one (which can be difficult to trace depending on the changes made).
♦Following will notify you weekly (There isn't an immediate notification option any longer - or not that I can locate) - in the meantime much damage can occur. The Following list: https://www.familysearch.org/tree/following/ might be easier to follow.
Anyway, hope some of that makes sense.
0 -
There are many reasons to connect a non-related person to a family with a relationship correctly identified as adopted, ward, or other relation options found in the New Person Page.
However, if a person was connected to parents and siblings through a mistaken notion that the person was a son and sibling, that person should be detached when information comes to light proving the mistake.
Am I missing something?
0 -
probably ... the Idea above gives as example several purportedly incorrect parent-child relationships - not unconnected person relationships.
Further, this Idea requests a way to reject a 'hypothesis'. There is no formal hypothesis in Family Tree - so you can't really reject something that isn't there - but yes, you should be able to reject an incorrect profile. This rejection is obscured in Tree - with only 'reason statement' - but no 'residual rejection' - sort of like Record Hint rejection but with an artifact/element/component that stays with the profiles concerned.
1 -
Hej, @SivPettersson
I'm not sure if your use of "hypothesis" is on purpose or a translation problem. Since Family Tree is a single, universal tree that we all work in together that was seeded with the contents of multiple databases that span about the past 150 years, there is currently a lot of incorrect, unsupported data in it. Part of our job here as users willing to volunteer our time and knowledge to perfecting FamilySearch's tree is to remove all hypotheses and replace them with solid, well supported conclusions.
When you find family information in FamilySearch's tree that you disagree with, instead of just marking it with the button you request as a new feature, please go to work and make all needed corrections. As long as you completely document your work with the supporting sources and put in any needed explanations it is unlikely that anyone would reverse your improvements.
You did not give enough information to take a look at the entry in FamilySearch's tree where your relatives have the wrong relationships, but I suspect that if you go through the records you are most likely to see that there are few if any sources, or that no one has touched the record since 2012, or that there has been in an incorrect merge you need to untangle, or that some work has been done by someone who has never looked at the original records or that clearly cannot read Swedish. There is a good chance that you are and will be the only person who will ever run across the people you mention who knows how to make the needed corrections. Please do so.
Med vänliga hälsningar.
4 -
I'll be the first to admit that every problem with the solutions I listed does exist. But in the end, I still think they are better than the alternative suggested. The ability to mark something as read-only would empower those who think they have the correct information but are in actuality nowhere near being right. In the Thomas Graves situation I mentioned last time, for example, the people researching had gone through two sets of parents for one of them, neither of which turned out to be correct. The same thing happened with three different wives.
As it turned out, there was a genealogist decades and maybe even centuries ago that combined all three Thomas's in his research, and to this day has confused hobbyists and probably even a few professionals. The errors came through to begin with when someone used that research as a source and changed basically everything. And the thing is, that person seems to have considered their information to be 100% correct. If she could lock it, I have no doubt she would have. Currently, if we encounter something like this, we can change it back. If it could be locked? We would have had to start over from scratch. And in case you are thinking, "Well, couldn't you have just locked it with the correct information before that happened?"
No. No, we couldn't have.
The three are so difficult to separate at this point that we can be sure about very little. Think about the chaos that several incorrect merges can cause, then multiply that by decades, and you get the Thomas Graves situation. It has to be left open to correction at all times, even if that means leaving it open to errors.
On a similar note, me and my brother recently discovered that one of our ancestors had two sets of parents listed. We did the research, and we determined that the false parents were the ones that had been listed longer. The wrong parents had been there since the child was first added to FamilySearch, in fact. Our ancestor had gotten confused with a cousin of the same name. If he had been locked to those parents, the error would have once again required us to start from scratch to fix. This, unlike the Thomas Graves situation, seems to be far less of an edge case, as uncommon names had to be paid for at the time, parents had more children, and names were often reused throughout the generations. I've actually found a similar instance in the few weeks since then, only the second has been far more difficult to sort out. The possible consequences of allowing someone to lock information I mentioned above still apply here, so I don't think it's worth getting into detail again, I just wanted to show how common these mistakes can really be.
0 -
Which alternative are you referring to? Read-only appears to be the one you are focusing on - while the one I am actually suggesting is 'polling' (based on existing tree(s) combined with Family Groups). Those edge cases you point out will be rarer for the more recent generations of relations in Tree - and if the Family Group is polled - mistakes will likely be found/fixed quicker (depending on whether a Family Group collaborates well with each other.
One adept Tree/Community user reports that - '[cousins are likely to have the most disagreeable arguments over Tree problems.]' So isn't it better to contain that disagreement within the Family Group where all - or especially 'elder statesmen'/cooler heads can prevail - rather than allowing the entire world to also join in? I realize this depends on engaging an entire group collaboratively - and that 'cooler heads' might actually be outside of the group. But realize all this Idea does is expose the group's agreement/disagreement to the world Tree - rather than a possibly empty Collaborate tab on the profile. Why not collaboratively come to Family Group agreement (or disagreement - whatever the result) and expose that with the 'settled' profile to the world Tree?).
So this Idea suggests leveraging existing personal trees and tree review/cleaning/fixing tasks done in Family Group context. If Community doesn't like the Idea of separate trees/contextual login - then perhaps these could be collaboration tasks (like Record Hints but preferably 'mandatory' - no point in polling if no one participates) sent to the Family Group - for 'Tree review/polling'. IF a Family Group we're 'super active' in Tree - I might even suggest such a poll be appended to a proposed 'change'. But I am sure open-edit Tree purists would not like this. I'm just trying to balance the obvious family interests of 'descendants/near relation descendant's with the interests of open-edit world Tree. This would be a different collaboration model/workflow. Hopefully it would be helpful. It might at least be worth a beta test ...
0 -
If that's what you meant, I didn't catch on to that at all. (Granted, I was mostly skimming it, because I was in a bit of a hurry.) The logistics of that change are complicated, but it may be worth implementing to some degree. If it applied at all times, then it may become too difficult to make simple changes, but I could see polling being implemented as part of the Family Groups feature. That may not really be a solution though, just a handy feature. Perhaps there could also be a way to mark something to be determined by a poll, but that could be difficult to regulate (What are the conditions that allow for starting or ending it? Under what circumstances can it be changed or removed?), and could even potentially make things worse if misinformation was too widespread. There are likely ways to deal with that, but I can't solve it off the top of my head.
0 -
The logistics of that change are complicated, but it may be worth implementing to some degree.
@BraydenGraves Logistics complicated? I'm not sure it is or what you might mean (perhaps we both need to clarify) - but maybe I am missing something obvious. I can see it being through 'My Tree' contextual login - but people are balking at that Idea - who knows why exactly (I don't think anyone has given specific enough reasons - just generally saying 'this Idea doesn't align well with Family Tree...) - not only does it leave open-edit alone but is also a change in collaborative model - rather than import (which can cause profile damage) it only exposes agreement/disagreement with the profile.
Ok, if people don't like that Idea I have another one that works only through current mashed-up Family Tree context. I'll try to share it later.
0 -
By logistics I mean the logistics of implementation. What you are suggesting is very complicated--not only in the sense of adding the feature, but also in determining how the user should interact with the feature. All my reasons for that are explained in the previous comment.
"rather than import (which can cause profile damage)"
Thankfully, importing was removed years ago, so you don't have to fear that anymore.
(Also, how do you only quote a single line?)
0
