SmartCopy for message receipt confirmation

If I'm understanding you correctly, a message sent to a manager of a profile, which I think would be a manual action, is done through Geni system and not something SmartCopy would be able to monitor or confirm.

Thanks! Sigh... do you know if the Geni system doesn't confirm that a recipient reads a message for privacy reasons, or is there a technical barrier for this?

Probably because the codebase they're using for their messaging system doesn't have that function. I'm happy it doesn't, though - the privacy implications of read notifications are subtle, and it's better to err on the side of privacy.

What are these "privacy implications"?

Many consider it privacy with regard to if they read or haven't read a message. They don't want anything telling the other user that they did read it and have chose not to respond. It also wouldn't work, because messages tend to send off an email notification with the message. So I can read it in my email and ignore my Geni message that would confirm I read it, giving you the impression that I ignored the message when I have in fact read it. So, it just wouldn't work as intended even if it was an option.

OK. Here's a fun one: From a business point of view, how would Geni be impacted if it required people to respond to appropriate messages?

Todd Michael Edelman how do you "require" any active action from people when you can't even "require" them to log in?
Geni's terms of service allow them to terminate the accounts of people who grossly abuse the system. That's something that works becaue it's a response to something they do.

I don't think it's possible to have terms of service that forbid not acting.

They could require Geni members to add at least one reference document OR some text about oral history.... they could require people to respond in some fashion... they could do a lot of things.

My point is .... what can Geni do when people don't follow the requirements?

If people don't login for a while and thus are unresponsive to profiles they manage, you can report their tree as abandoned. This will transfer management of their profiles to the closest active family member, who will hopefully be responsive.

This is also a reason why it's good to have multiple managers on a profile, either by request or merge, so more than one person gets contact manager messages. There is also the follow ability where others will see discussions of profiles and that may automatically apply to profiles in the family group.

Curators are also here to help if someone is unresponsive. We can merge branches or make corrections if you're having trouble doing so.

So there are some mechanisms in place to deal with absent managers.

Thanks, Harald! Thanks, Jeff!

Jeff, to your points:

* Does Geni or do you suggest a non-responsivity threshold? Do they do their own investigation? They fully transfer the Profile, or just add another -- I'm trying to be specific as I could imagine that if they end up logging on again later, they'll see messages from someone immediately prior to this event and perhaps correctly ascertain that they are the ones who reported them.

* Merges, okay -- but I would assume that many will deny a Manager ask - if they even see it - for the same reason they'll not respond to a query. Can Curators add Managers to a Profile?

* Yes, I've had a lot of help from Managers with these issues :-)

***

But back to the bigger issue:

* Becoming a Manager is one thing but it won't mean we'll suddenly get answers to any of our questions.

* Not adding any source documentation, or even mentioning city/town/village or least a country as place of birth or death etc., makes a lot of work for others, often for no reason as the location is probably known to some Managers. Sometimes there are clues and the person can be researched on Family Tree or on Ancestry - re: the latter easier if we can scale the paywall. (Not supporting a Profile in the most minimal way is akin to building without permits; doing as much as you can to support one is respectful deconstruction - of course I don't mean "demolition" - and this relates to my view that none of us are building trees; we're revealing our families and others on the Tree that's already there.)

So.... my "business" question relates to solving some or all of things I mention -- I think it's fair to say that for many this would create a higher quality experience that will encourage more peer recommendations for Geni and more Pro-level Memberships. It also seems that improvements which are automated after implementation would not create a lot a huge amount of extra work for them.

I'm not sure what the timeline is for being able to transfer an inactive tree to another family member - I think maybe if they haven't logged in for 1 year. Curators can not add managers to a profile.

From personal experience I believe the "abandonista" period is somewhere between 9 months and 1 year. Although Curators cannot add managers to a profile, Customer Service can, and does.

This is another way SC is such a valuable tool. Facts are facts, and sources are sources. Doing proper research before entering into Geni, whether through SC or by manual citation, helps collaborators, Curators, and Customer Service determine that these matches and merges are good.

"Abandonista claimants" are another matter. This is a subclass of inactive user who happens to have claimed their profile, then abandoned Geni. There are about 10 of those in my tree, all within my MAX Extended. Without Curator tools, I can't edit their profiles or deduce their Last Online. But I can see their Last Activity on their immediate family is 2 years or more, therefore the timeline is longer on this subclass of abandonista.

I haven't kept a good list, but even Curators couldn't do much about them after I've cleaned up these abandonista messes as best I can after SC merge. It's not a big concern right now given the overall amount and quality of profiles entered by me into my MAX Extended.

At the end of the day, sending a message to an abandonista is akin to waiting for Godot ...