Should the 30-day automatic approval for merge proposals with unresponsive managers, be shortenend to 14 days?

Question

Chris Whitten (it was his suggestion to start a separate feed on this to get clarity on the issue) would like to implement some technical changes (see this discussion and specifically his answer to my question) but would appreciate proper discussion on this issue of changing the auto-approval time period from 30 days to 14 days.

There have been many suggestions and some discussion in the G2G-feed for shortening the waiting period:

The most recent one being exemplary: Is waiting 30 Days for a merge from a long gone profile manager ridiculous?

A short summary of points (and spin-off issues):

• It takes too much time (Biggest grievance with WikiTree is needing to wait 30 days for a merge when the profile manager has long since gone.  It would be nice to remove this delay for profile managers who have not been active for over a year. Even if it was over 3 years, that would speed up a lot of merges for profiles created years ago by people who were only on WikiTree for a few days and loaded a Gedcom and then never came back or gave up quickly.)
• Would also like to see abandoned profiles ( no login by manager in say three years) be put up for adoption and if there private set security at a safe, but view able status.
• Would there be away to track activity, and automatically remove Profile Managers who have been inactive for say more than a year?
• Wikitree needs some mechanism to handle people who leave. We all will at some point.
• At the bottom of the page "Unresponsive Profile Manager Request Form";This can be used to orphan a profile. You need to do three things before you fill out the form. Make a trusted list request / Send a private message or email / Post a comment on the manager's profile. This takes about two to three weeks, shorter than 30 days
• There are many reasons why people become unresponsive - spam mail, illness, inability to work with / comprehend / adapt to WikiTree technical challenges (user friendliness).

I would suggest that unresponsive managers is the real issue here, and the question of shortening 30 days to 2 weeks waiting period the discussion.

Though I personally find a 30 day waiting period for automatic approval just enough time to complete the many merges proposed within the project that I am project coordinator of (as well as regarding my own personal genealogical WikiTree work),

Sometimes it is (in my case) much quicker to just create a duplicate profile with the correct spelling of the LNAB and then propose merges into them, than to correspond endlessly on countless profiles with managers that I know are inactive and non-responsive, after which a unresponsive profile request (also taking two weeks) results in many more profiles being orphaned off, something that is'nt always a good solution. This is simply not a feasible option when coordinating a pre-1700 to appr. per-1800 project with multiple (and massively merged) profiles [total number + 8000 profiles]. It costs enough time already to stem the flow of new duplicates through proper / adequate greeting / follow-ups and mentoring.

Please feel welcome to edit this question (leaders) - I'm not sure if I'm succint enough in my summary.

Comments

"what does help is at times intense mentoring and behind-the-scenes guidance, and loads of outside of WikiTree email correspondence."

Thank you!

I wonder if the job of profile creation and should be automatically linked to the job of profile curation to begin with when we are dealing with pre-1700 profiles. It seems like there are people who very much enjoy the task of being curators on a daily basis and others who like me prefer to do research and add content. I would honestly prefer to hand over all pre-1700 profiles to pool a well trained and well staffed team of curator volunteers who can handle all the small daily details and anything big can be forwarded to G2G with a link back to the profile. Perhaps leaving the option to "follow" communications regarding certain key profiles I'm concerned about. I haven't thought about how this would all work exactly but the current system does present challenges.

---

I have some  "second thoughts" about this proposal to shorten "automatic approvals" for merges after only 2 weeks.  I see the Pros because I too get frustrated sometimes waiting for an unresponsive manager to approve what seems (to me) an obvious merge, especially one under 200 years old and so "green" badged.  BUT I also see some Cons and Liz has expressed the most-important one - it's a lot harder to Undo a bad merge than to allow a good one to wait a month.

 

If we are going to approve this change, I would like to see it accompanied by

 

1) a Limit on how many merges a member can complete in 24 hours - exempting Arborists and Leaders and Project Coordinators....

 

2) stricter controls or better programming for the "matchbot" robot - it suggests merges based on just name and birth year - 90% of the time for completely unrelated people (that a human can see at a glance because one was born in the USA and the other in Australia etc.).  Last week I went thru a week of matchbot merge approvals - thankfully other managers had rejected 2/3 of them but I had to examine and reject nearly all the other third, going back over a week.  Only one of some 30+ suggested merges "might" be a good merge - but the 2 profile histories were very mixed up and would have to be untangled PLUS the parents would have to be merged or sorted out too.... I made it an Unmerged Match with a comment as I did not have time to do all the sorting (I have a big 21st Century event this weekend in my life).

 

Imagine this getting in the hands of a "merger member" - we have them - who troll thru approved merge lists and combine profiles speedily, usually with NO clean up and sometimes ignoring the warning to merge Parents first..... They go thru dozens of profiles a day - I think we've all seen it.  So a 24 hour limit on merging might be a good idea.

 

Anyway, sorry to be "venting" on this; shortening the time could be good for some members; perhaps another way to make this work would be to add a 3rd change to differentiate experienced members (who could merge within 2 weeks) from those who are new or infrequent contributors: who must wait a month  - perhaps the 2 week rule could apply only to those with pre-1700 Badges OR to Leaders, Rangers, Greeters, Mentors and Arborists and.....?  

 

I am not sure that's what Chris is looking for, however, and I agree with him that we do not want to go towards creating "sub-members" or "super-members" (other than the specific groups we need to do specific chores).   Overall, perhaps, IMHO, best to "let sleeping dogs lie" as the system is working OK - isn't it ??

 

I am delighted about the Image Links change - bravo!

---

I like Chet's comment and agree with 1. As for the match bot--I thought wikitree was supposed to be a 'people' tree, and therefore I'd like to see the matchbot simply disappear from the site. I too see erroneous matches an actual human would never make--it needs to either look at more information to base it's suggestion on, or not make suggestions IMHO

---

I would like to see the 30 day default time period retained. Yes, it is a pain in the neck, but bad merges are much worse, in my opinion.

---

I like the idea of reining in the matchbot. One way to do that would be to ask the bot to generate a report on possible matches it finds, to be turned over to a human who will look at them and propose merges (or post unmerged matches, if appropriate)  for those matches that appear to be valid.

---

The Arborist project would be willing to take on the list of Matchbot merges found....

---

Bravo, Robin - I hope this will be quickly adopted, especially if we shorten the waiting time for such merges to be approved.

---

I like Ellen's idea too.  I hope Chris can implement that.  And Robin, I'd join the arborist group just to help monitor that! :)

---

Given that the vast majority of my proposed merges go unanswered, I'd be in favor of anything that facilitates the process of getting things done. Either streamline this process and/or (another beaten to death topic) require open profiles for people that have been dead 50 years or more. To me, the notion that someone who died in 1930s-1950s death certificate is public record but I have to deal with a privatized profile for someone who died in 1850 doesn't meet the test of reasonableness.

I proposed a merge yesterday of my sourced profile with an unsourced and data-poor profile with a profile manager who is active but will not respond. The profile manager copied all of my data over to the profile he manages but didn't respond on the merge. Presumably, I'll be waiting 30 days to do what should have been done in the first place, which is very annoying.

---

if you are talking about Carr-5062, it looks like the profile manager approved 20 minutes after you proposed the merge.

Answer 1

I'm not bothered by the 30-day wait. I am bothered that when one of the profile managers approves the merge, that resets the 30-day clock. If I'm offline for a few weeks and come back to find a merge proposal that I agree with, my approving it *shouldn't* reset the clock; the other manager doesn't need extra time to decide just because I've said "yes, this merge is fine".  Is that something that could be changed without massive programming anguish, or is it something we're basically stuck with?

Comments

This is exactly the reason why Chris wanted to have this discussion.

---

I completely agree with Sharon!

Answer 2

30 or 14 days only? could we compromise with 21 days? This would give some buffer for 2-week business trips/vacations of active managers. If there is a way to have different standards for active & years-inactive profile managers, I don't see that the latter group needs even 24 hours.

Comments

21 days seems like a good time period for active managers.

---

I'm for anything less than 30 :)

---

In principle, it would be nice to give active and responsible profile managers  three weeks to accommodate vacations, but in practice I don't think it's needed.

I believe that it's extremely rare for a bad merge proposal that involves at least one profile with at least one active and engaged trusted-list manager to get to default approval. Most merges that get to default approval either involve at least one profile that has no trusted list members who are paying attention.  I have seen a few merge proposals that ended up being stopped by a profile manager (or trusted list member) who stepped in and explained that the two profiles were actually different people. I think in every case this occurred less than one week after the proposal was made (usually a lot sooner than one week). Accordingly, I think 14 days would be plenty long enough.

The rare case of an active manager who is on a 16-day vacation and misses a bad proposal that gets completed quickly by an eager contributor is too unusual to be the basis for policy.

---

Speaking of TL members reminds me that they don't get notifications except by weekly feed, which many people ignore, so often they don't know what's going on.  Sometimes merges don't appear in change logs, so they might not be in feeds either.

Orphans are treated as nobody's even if they have TL members.  The idea of being trusted by nobody in particular is odd anyway.

Managed profiles go to default even if they have TL members who are unaware.  The approvals aren't logged or notified.

There's no way to communicate with TL members except by going through the list and messaging them all separately.

A G2G thread about a merge can only be attached to one of the profiles involved.

More generally, there will often be people out there who could usefully comment on a merge, either to block it or to say, I know these people, this is OK.  But the system doesn't find them, and if they did want to vote yes, they'd have no way of doing so anyway.

---

RJ - Re TL notifications - Don't merge requests show up in the Family Activity Feed that shows up on the Navigation Home Page?

---

Good point about TL members not getting notifications. I'm not entirely clear on what generates a notification and what shows up in the family activity feed. I think that most active contributors monitor their family activity feeds pretty regularly, so they will see merge requests if they appear in the feed.

However, recent experience leads me to think that TL members may not see a merge proposal unless we are on the TL for the profile where a comment was posted. On a few recent occasions I've been surprised to discover merge proposals I had not previously been aware of in "Pending Merges Waiting for Action by Me."  I wonder if these are instances where a merge proposal was made without posting a comment, or where I'm not on the TL where the comment was posted.

Answer 3

Could somebody clarify exactly why we're waiting for responses from PMs anyway?

There seems to be too much being taken for granted that maybe shouldn't be.

Comments

I tend to agree. If I should wait for responses of all the MP's on profiles, I'll need 10 more years ... luckily when profiles have 3/4/5 or more managers, it is easier to reach an active and responsive one. I do not waste my time on trying to communicate with PM's that I know aren't responding anyway. Even an unresponsive manager request is often too time-consuming, can at times be detrimental (I once after having orphaned off many profiles this way from a non-responsive manager, got a bitter response from him that I had just taken away his "happy place" ... some managers are not that quick to respond because they see this more as a hobby than an urgent quest to correct data and genealogical lines), and then one has the issue of other soon-to-be non-responsive managers adopting them (out of sight, out of mind).

I have to prioritize my communication time in and out of WikiTree with those people who are actively & dilligently working away trying to validate profiles, and those that need welcoming, instructions and are eager to partake ...

---

Seems to me too many verdicts are based only on unsourced info on the profile itself, which everybody can see.

I'd like a rule that unsourced info can't be relied on.

And also, nobody can be a PM on an Open profile unless there's a source posted to identify the person, or they can produce one on demand.  If they don't know who the profile is supposed to be, how can they manage it?

Exception for topical projects, which might adopt profiles in their territory before they investigate them.

This is wandering off topic.  But I'd wait 30 days for a legitimate PM with a fair claim to be consulted.  What annoys is waiting for meaningless and pointless responses.

---

This is where I do not agree with you RJ. There is in my opinion no relationship (causal or otherwise) between the [perceived] validity of sourced or unsourced info in profiles, and the amount of responsiveness or activeness of profile managers.

I'm sure that most of us will agree on that unsourced info can't be relied on, but this isn't the issue at question here.

Also, your statement "And also, nobody can be a PM on an Open profile unless there's a source posted to identify the person, or they can produce one on demand.  If they don't know who the profile is supposed to be, how can they manage it?

Exception for topical projects, which might adopt profiles in their territory before they investigate them" is unclear for me.

Could you perhaps provide more context - what are you saying here? Moreover - how does it adress this particular question above? (the time period). If it does not relate to the above question, it could be adressed in another feed (there have been many G2G discussions on what sources should and shouldn't be).

---

I was suggesting that we're in a state of terminal confusion about the role of PMs on Open profiles.  Why do we want to have them and ignore them?

If their say-so isn't worth having, why are we asking for it?

It's not only about totally inactive managers.  Any reduction will apply to temporarily inactive managers as well.

In any case, we're now being told that if one PM wakes up and approves a merge, this restarts the clock.  Should we post messages saying Please do not approve this merge, it'll go faster if you don't?

Or should the PMs compare notes, and not approve anything until they've agreed that they both will?

In any case - I never get an answer to this - why don't people just get added to the TLs if they want to control and speed up merges?

---

Bulk addition of a pool of people to all trusted lists of all pre-1700 and post-1500 profiles would be a great idea in my opinion. I don't know what the mechanics would be RJ but if we could work out a system that basically hands all these profiles over to a system with group control I think we would all be better off. That's just my opinion.

---

In response to "why don't people just get added to the TLs if they want to control and speed up merges?":

In my experience with profiles that are "managed" by absent or inattentive PMs, the 30-day wait for default approval on a proposed merge goes a whole lot faster than the process of getting added to the Trusted List.

The merge usually can be completed in just 30 days. In contrast, when the "manager" isn't managing, getting added to the TL requires:

• A TL request, including a pleasant message that, for example, explains that this person is my sixth great grandmother, that I appreciate the effort that went into the gedcom upload that created the profile back in 2011, that I've added sources and content to the profile, and that I'd like to watchlist it so I can continue to collaborate effectively in the future.
• After giving the PM(s) plenty of time to respond (usually at least 14 days, often longer), a profile message and a private message (maybe both at the same time or maybe a week or two apart) repeating the same information and providing details of the process for adding me to the TL (because most members don't know how to find their Requests list nor how to add an email address to a TL).
• At least a week after the last message, an Unresponsive Profile Manager request, followed by another waiting period of a week or more. 

That process normally takes at least twice as long as it takes to get default approval for a merge.

---

Exactly Ellen! Thank you!

I think all pre-1700 profiles should be automatically transferred to some pool of volunteers to be curated. One big trusted list if you will. I concede when we are handling profiles from the last two hundred years a profile creator may have personal knowledge that allows them a special ability to curate their own family. But when we are dealing with pre-1700 profiles we are all using the same sources: Vital Records, Probate Records, TAG, Anderson, etc. Either the merge is clear or it needs to be discussed on G2G. But the profile creator of a pre-1700 profile has no personal knowledge that makes them a better curator than anyone else. Anything they know can be spelled out on the profile with citations. Pre-1700 profile creation should not be linked to profile curation.

---

Yes indeed Ellen, this is my experience as well!

---

Thanks for the explanations. Personally I've never tried joining anybody's TL, I was just wondering why the system isn't used as intended.

If I did, I wouldn't be claiming to be a descendant.  I gave up trying to keep track of who my ancestors are today.  I didn't realise that being a descendant was expected for Open profiles.

As for Roland's thinking, I think just removing PMs would do the job.  People would then effectively have full and immediate control of their own Watchlists in that area.  Except that presumably adoption on behalf of projects would be allowed.

Actually most pre-1700s are covered by projects.  But that's another thing that makes this whole discussion peculiar.

---

I just had a frustrating encounter with a Profile Protected PMger (pre-1800) who after a 2nd request in more than one month, simply send me a message saying "Sorry, not active on Wikitree anymore". There should be a mechanism in place to automatically disown profiles from WikiTreers who still respond and who are active enough to add tags on their homepages to follow (this was a recent addition / feature of WikiTree), but who remains braizenly inactive not even to comply with a simple request.

---

@RJH And also, nobody can be a PM on an Open profile unless there's a source posted to identify the person, or they can produce one on demand.  If they don't know who the profile is supposed to be, how can they manage it?

Really? So if I adopt a profile that has no sources are you suggesting I should not be able to do so. Also many GEDCOM imports have what I call pseudo-sources. They do not identify the person and are mostly a load of verbiage with a single link to Ancestry.com. We don't have all day, well actually I do :), to be on WikiTree so what time period would you suggest would be reasonable before someone is unable to be the PM of an unsourced profile?

---

I'd need to understand why people want to be PMs on Open profiles, since their only function is to be obstructive and anti-collaborative.

Actually, of course, there's one good reason to be a PM, which is, if you don't, somebody else will, and then you'll have to go through them.

It's just a scramble for territory.

---

Territory, as you put it, is irrelevant particularly as I believe there is a limitation anyway on the number one can manage. Under the current system if you come across, as I do from time to time, two duplicated unadopted profiles then you have no option. To suggest that the only function of a PM on an Open profile is to be obstructive and anti-collaborative is, in my humble opinion, a somewhat jaundiced view of the world. I have found most to be more than helpful.

Having said that I do agree that once a profile is Open than all the functions possible should be freely available. In order to achieve that however the automation of privacy determination on 100 and 200 year old profiles needs to be looked at, in particular with a view to the date of death. That done, the way would be open to the removal of PM's from older profile except where it is a PPP when any PM should simply be a project member.

---

You can merge orphans without adopting them.

In any case, if a profile is orphaned, you can always adopt it temporarily if need be, and then leave it orphaned for the next person.

Yes many PMs are helpful, but they're helping you to do what you could otherwise just do for yourself without needing their help.  What's the logic?

It's like, I put a locked gate at the end of my drive, and a bell-push, and if anybody rings the bell, I run out and helpfully open the gate, which wasn't necessary when there wasn't a gate..  The PM isn't just me, it's also the locked gate.

---

You can merge orphans without adopting them.

I was not aware of that. I will try it.

In any case, if a profile is orphaned, you can always adopt it temporarily if need be, and then leave it orphaned for the next person.

Indeed.

Answer 4

Imagine if Wikipedia had five or six separate pages about the same topic. Imagine that some of these pages are information rich and others are spotty or worse filled with totally wrong information. If you use google to search for data on a topic and land on the bad versions of pages on Wikipedia over and over you would quickly learn to avoid Wikipedia altogether.  And this is the tragedy that we face right now on Wikitree. The great information offered here is lost in the noise of poor quality replicas imported from GEDCOMs and long since abandoned by PM’s that haven’t logged in for over a year.

The utility of Wikitree is severely handicapped because of the excessive number of abandoned duplicates that exist. Researchers searching for data using Google land on the wrong profile - one which lacks a high quality biography and sources. Too often they end up missing the well sourced duplicated profiles altogether. They miss out on what Wikitree has to offer. And the number of hits per profile declines because researchers are not finding on Wikitree what they are searching for. Some of our very best research gets very few visits as a result. We can present the best research possible but if no one reads it what good does it do?

This impacts project performance. I know firsthand that PGM’s progress is being severely hampered by the number of duplicates that exist. We try to get them merged but after a while talented content creators in PGM often just give up and move on and forget to come back. No one wants to invest days on a PGM profile when there are many other copies of that profile, its spouses, its parents and children yet to be merged.  

95% of the mergers that need to be done are no-brainers. They are intended to be the same person. They should be merged. The PM wouldn’t object to the merger on the grounds that they represent different people. The PMs are simply no longer active members.

Aside of the above if there are doubts about the merger it should be brought up on G2G anyway. Any genealogical question should be discussed openly. Any profile in a project is discussed by all interested parties.  

If there is no doubt and you don't receive an objection in 14 days I think the merge should proceed because the benefit to Wikitree and its users will outweigh the cost of a rare accidental merge causes by a PM on extended leave.  

I have to concede that in a few cases the PM might be on an extended trip and this could be an issue. However, we have to balance the costs against the benefits. Sure there is a risk that rarely an incorrect merger could precede. But in most cases we are talking about profiles that have no biography and no sources and have incurred minimal effort. They are easily recreated. Well sourced profiles are not confused and merged so easily.

I think 14 days would be better than a month.

Comments

But surely what's needed in most of the cases you're talking about is to remove or replace the disappeared PM.

Projects have the additional option of taking their profiles under management-by-project.  A Leader installs a team member as a PM.  Problem solved.

---

RJ - I think I would be posting a lot of "PGM / Leader" G2G posts requesting administration of profiles then. Maybe that's the solution but it seems to be time consuming for Vic (the PGM leader) to do this. If I have five copies of a profile and five spouses and several duplicate children that's a lot of monkey business to get me installed as administrator on all those various profiles before the merge can occur. Also how do I even know that the current PM is unresponsive until I've waited a couple of weeks for a response? Another issue is that the profiles that need to be merged for PGM are often not PGM profiles themselves. They may be parents or spouses or children. But they are not covered by PGM. We just try to straighten them out to reflect a single accurate genealogy around the primary PGM profile. I'm not saying you are wrong either. It could be a way to go. But I think we would need more than one leader for PGM to do this because with 20,000 PGM profiles and their respective families that's going to be a lot of work.

RJ what do you think about making all profiles born pre-1700 and post 1500 added to a PM pool or a big trusted list pool? Maybe this could just be done in bulk and we could have volunteers in the pool.

---

So much for projects.  What's the use of PPP and management-by-project if it never gets to first base because the Leaders can't install the Managers?

This keeps happening.  A scheme appears, full of good intentions.  But the object is never achieved, because the scheme is never made to work properly.  Then it hangs around as a pointless lingering nuisance while people find a new frustration to point the finger at and a new scheme appears.

When locking of parents came in, it was said to be essential that PPP was restricted to appropriate cases and non-project PMs were removed.  Mostly those things aren't happening, so that scheme will fail.

Remember when pre-1700 was the answer to everything?  Less than 18 months ago.  Can't remember what the point was now.

Default approval is one scheme to defeat another.  Because the other was seen to be unnecessary and unworkable.  But the scheme to defeat it isn't working either.  What's wrong with this picture?

14 days isn't enough for anybody with a life.  Either we need to give people more than 14 days, or we need to decide we don't really need their opinion anyway.

---

14 days isn't enough for anybody with a life.  Either we need to give people more than 14 days, or we need to decide we don't really need their opinion anyway.

Must be easy to check the statistics 

1. How many people are active and how often active people return
2. People who don't respond on merge request when did they last visit Wikitree
3. .....

 

---

I get your point RJ. It isn't working as well as it could be. But projects do provide a point for focus, collaboration and communication that I don't believe would be there otherwise. I have wingmen (wingpeople?) in projects that I communicate a lot with behind the scenes and coordinate tasks with. So it does help. But I agree that we have a flaw in the PM area.

Magnus - possibly. Or possibly just replace any manager of a pre-1700 profile who has not logged in for six months and place management in a pre-1700 trust. That would solve about 70% of the problem I believe.

---

Re Or possibly just replace any manager of a pre-1700 profile who has not logged in for six months and place management in a pre-1700 trust. That would solve about 70% of the problem I believe.

Isn't Wikitree big enough now that we should start gather statistics in a better way? 

1. Question likes above
2. How long does people stay as active members and when they quit why
3. How many viewers pages inside a project has....
4. Number of users on Category pages in an easy overview

Feels we are guessing when all the facts exists in the system....

Answer 5

I suggest that we on the profile page of users add Responsiveness

And base that on number of responses and average days...

==> 

1) it will encourage people to be a good member of the Wikitree community and act faster....if people would like to investigate the merge more before making decision then maybe add a flag saying I am looking into this merge and will come back with my final answer soon....

2) other users who is suggesting a merge can check the profile managers profile and see what they can expect in response time....

---

The example above is from a site I am member in called www.warmshowers.org that is even more dependent that people cooperate than Wikitree. 

User story Warmshower

As a person biking around the world and arriving to a location I would like to send a request and get a response fast that I can stay at someone's home, I will then meet local people and learn more ofbout the country I visit and I will also get a cheap stay and can save money

You register on the site and tell other people bicycling around the world that they can stay for free at your place or when e.g. I was biking in Vietnam 2015 I contacted people to stay or just meet them and get advice....

Comments

In short - a ''responsivenes''-indicator (or activity-meter) on the profile page of every WikiTreer.

Might be a good suggestion, but it needs to be somehow technically linked to another process where the general situation that Roland schetches above is attended to (improvement of quality, reliability of data, reducement of duplication [also in terms of internet rechearch]) and the issue of the auto-approval time period from 30 days to 14 days is addressed.

---

Maybe add more steps

1. Step 1:The profile manager on the "target" merge profile signal he/she has received and set status==>  
   1. I have received your request yes merge
   2. I have received your request reject
   3. I have received your request and will come back with a decision later

On WarmShowers you can also set up that you will not be available until date xxxx ==> the bicycle person who is looking for a stay next week in a city dont ask this person.....

It's not easy to collaborate over the Internet ;-)

 

---

Magnus - you are always thinking out of the box. I love it.

---

@Magnus: you can also set up that you will not be available until date xxxx 

Perfick! (Darling Buds of May)

Answer 6

I absolutely disagree with a universal 14-day approval.  Life happens, folks. Accidents, illnesses, business, family -- two weeks is not very long when there's a crisis.  And I'm sure we've ALL seen merge proposals that never should have even been made.  Do you want to come back from a family emergency, or even a vacation, and have to deal with a mess someone's made of profiles you manage, or profiles in your project?  What's the gain in that?

Having said that, I absolutely DO agree with finding a way to remove long-inactive profile managers.  And that, in itself, would speed up a lot of these merges.

Comments

What about 

1. being able to assign another person in charge of handling the requests you receive during your month away? 
   A proxy person
    
2. a status telling I am away for next 3 months and will not respond ==> the person requesting the merge will get a signal nothing will happen 

---

Somebody completing a default-approved merge with 6 PMs on each profile isn't going to check out all the PMs to see if anybody is away.

We're just going to get a new species of complaint - I left a note but it was ignored.

---

Somebody completing a default-approved merge with 6 PMs on each profile isn't going to check out all the PMs to see if anybody is away.

Isn't that just a user interface discussion?!?!?
 

1. A Pop-up telling this will take time
2. Dear Template:Red or something else to warn a person.... that this will not be confirmed today.....

If the information is in the system that you are away then it can be presented in reports or when applying for a merge.....

If the information isnt in the system then Huston Huston we got a problem.... to know..

Also a proxy approach could be that 

1. I am away send it to proxy
2. I havent acted on 2 weeks ==> send it to proxy

---

Be very careful how you display information regarding when you will be away. Burglars love to find databases that show when people will be out of town. I know locally they mine databases from newspapers subscriptions and have even infiltrated the post office. As information technology gets easier to use organized criminals are only all to eager to use it. So I never post on my profile that I'll be away.

---

If the information is in the system that you are away then it can be presented in reports or when applying for a merge.....

Extensions to the database schema are rarely contemplated, if ever.  (If they could happen, there'd be so many...)

Templates in bios only give you MediaWiki facilities.

 

---

>> Extensions to the database schema are rarely contemplated, if ever.  (If they could happen, there'd be so many...)

Sounds like an odd development environment.... just creating a new table with key user-ID seems not rocket science....

>>Templates in bios only give you MediaWiki facilities

Dont follow what you try to say....

---

Be very careful how you display information regarding when you will be away....

Think we have 300 000 registered users and I have no statistics how many are active (done something the last month)..... 

I doubt that people not active the last year inside Wikitree are out travelling..... taking a Wikitree break is maybe more a signal that you found better things to do or Wikitree was not good enough......

---

I'm assuming that a bio is basically MediaWiki source which is "executed" by the MediaWiki "interpreter" when saved, and again when viewed or accessed in any way, and the only access to content is through the API provided.  All very clunky.

---

But the bio is not the place to have it... as its about the user.... it should be on the settings page is my vote 

---

Templates in bio and the semantic Web gives other possibilities

I feel a little bit sad that we don't think templates and semantic web inside Wikitree. An interesting article about something called the semantic WEB Semantic Data Extraction from Infobox Wikipedia Template  and how an infobox can be reused....

There is also an interesting free training "Introduction to Linked Data and the Semantic Web" at future learning.... Learn the power of Linked Data, explore how it’s revolutionising the web and get to grips with it by writing queries in SPARQL.

==> open up that data we add about a profile or a category could be moved to an database and the query language SPARQL....  ==> we could make Wikitree a big genealogy resource....accessible through a database.....

---

I agree with Nan in that we should focus more on the overall problem of locked profiles created by long-gone managers (say 2-3 years and more). For those profiles, at least, we need a more direct route to opening them for editing, merging, and adoption.

We should also create a specific procedure to open orphaned but locked profiles that clearly represent long-deceased individuals.

If we can establish specific procedures to tackle these two areas, we still need to decide on the mechanics of completing these tasks. Will we create a bot to handle these tasks; will we need volunteers to step forward (and how do we determine qualifications); or can current procedures be tweaked for these areas?

As for the title question, I vote no for any generalized changes..

---

But what a lot of people seem to be missing is that this reduction to 14 days is for PMs who have been gone for 3 YEARS.  If you have been away for 3 WEEKS, it wouldn't apply to you.  So there doesn't need to be a panic.  There would still be the 30 days for active managers, surely.

Answer 7

It also occurs to me that PMs who don't approve merges might be deliberately abstaining, rather than AWOL.  They might be saying, I gedcommed him off somebody else's tree, I don't know anything about him, I don't want to be involved, I'll leave it to somebody else to decide.

But there's no way to record an abstention, you just have to pretend you aren't there.

Comments

"you just have to pretend you aren't there." I'm picturing a possum playing dead :) LOL

Indeed RJ this does happen.

---

Sometimes profile managers remove themselves from a profile after receiving a merge request. That's one way of "pretending not to be there."

Unfortunately, however, the system doesn't notify the merge proposer that this has happened.  I've had several cases where I proposed a merge, it quickly got the first approval (whether by me or by an alert TL member), and I waited out the 30 days for default approval on the the second profile; then when I went to complete the merge I discovered that the second profile was now an orphan -- and the merge probably could have been completed weeks earlier if only I had known!

---

3rd party non-TL proposers don't get any info on approval status - either by a TL member, or by default, or by orphaning.  They get an email to say it's been completed, or eventually they find it highlighted on "Initiated by me/All of WikiTree". (Not on Waiting for Action)

---

Indeed, RJ. I check "Pending Merges Initiated By Me" regularly to find merges I've proposed that have "timed out," so I can complete them.

But when someone resigns from a Trusted List, their resignation isn't logged at all -- and it doesn't change the status that displays on the "Pending Merges" list.

Answer 8

I disagree with this proposal.  People often take 14 days for holidays - we should not assume that because someone cannot answer an email quickly that this means they don't care or are unresponsive.     

I don't believe irreparable damage will be done to the wider tree by waiting two extra weeks.

Comments

I think the issue is balance. How do we balance the need for a unified tree with the need to be patient for a response? And while it is true that the merge of one profile being postponed has de minimis impact there is a chronic issue that has been allowed to metastasize. The number of duplicate profiles has grown to epic proportions. And so the need is serious. And the need is only going to get worse over time as more and more members retire and / or die. Ultimately if left unchecked it could make Wikitree useless. That’s a dramatic statement, right? But look no further than FamilySearch. It is a wonderful tool and you can build a nice tree back to about 1700. But if you look at the pre-1700 there are hundreds of copies of identical profiles all mixed up in a soup of incorrect parents and spouses, etc. That’s what we are facing unless we take the pruning and merging task much more seriously.

 

I’ve done a lot of mergers and I can’t think of a single case were someone came back after the merge and said – hey I was away and I object to what you did!!! It has never happened. In every case I get answer within 1-3 days or I get no answer at all. So I think we are trying to tip-toe around an issue that really doesn’t exist or at least rarely exists. The impact in each specific case is small but the impact in total is huge.

Answer 9

Philip, the other issue your proposal does not address are abandoned profiles whose privacy settings are to red or yellow but are clearly duplicates ripe for merger.   Slightly outside of topic, I know, but there are literally hundreds of unmerged or pending mergers out there that never get processed for this reason - just look at the at "all unmerged matches" feed to see what I mean.  

For me, this is far more frustrating than waiting 30 days because at least profiles set to "open" privacy settings will get sorted out in the end.  The reds, yellows and greens (sometimes) can sit there for ever.  You can never get these closed out without going through the unresponsive manager tools which are quite laborious.      This is far worse problem if you ask me - there must be hundreds of duplicates out there hiding away but we can never see them because of privacy settings.

Comments

I can only agree. And proposing mergers on them make them hang around in limbo ...

Answer 10

I  think 30 days is reasonable and should be left as is, for active managers, and shouldn't be changed.  Sometimes I get multiple requests in the same family line all at once.  Someone starts clicking on merges of every family member -often because of uploaded gedcoms.  Often with erroneous data.

Each one needs to be checked and researched prior to merging.  Sometimes they have different parents/spouses/spouse's wrong, missing, etc. LN.  Particularly if they are part of a project.

This takes time.  And if I'm away, and not able to do the research, to approve, query, reject, confirm, then in 14 days the merges would be completed, and left in a mess.

Some have mutliple PMs as noted, and queries go between them.  Or someone you want to confirm with, happens to be away themselves, and isn't seeing your message.

I do agree that inactive PM's, probably shouldn't have a say in it!!!  Hey, if someone is inactive for 2, 3 years or more...

I'd rather see a method of removing someone as a PM is they are totally inactive.

But I MUCH prefer the 30 day window for merge approval.

 

Comments

I have to agree with you Chris!

---

Three leaders (one of them being me) were discussing this issue - I quote from "Like Becky, I am having second thoughts because of those "auto - mergers"  types of WikiTreers that make bad merges without exploring deeper into what they are doing................rangering and catching them is not enough )-:

Maggie

---

I tend to agree with Liz - I've had to deal with bad merges from people who specialize in merging the auto-approvals and seem to be waiting daily to do them.

Becky Syphers

-----Original Message-----
From: Liz Shifflett
harm? hundreds of hours fixing bad merges.

---

Regardless of what happens with the 30-day waiting period, it seems like it would be a good idea to automagically remove people from PM status on an Open profile (but leave them on the Trusted List) if there has been no activity on their account for a one year. That way, people who are deceased or have lost interest won't be able to continue to block progress.

---

Maggie, what if I may ask is the issue then here - the time frame of 30 days auto-approval (because of non-responsive managers) or the merging of auto-approved by those "auto-mergers" types of WikiTreers that make bad mergers without exploring deeper into what they are doing ....?

A few spinoff-questions/statements:

• This is exactly the reason that I am so anxious to merge our project profiles ourselves because we (our active project members are educated in the sources and history and have no problem recognizing most sources, even though the sources might be not that well cited or of doubtful quality)
• Every weekend I have to spend half a day going through all the profiles on All Pending Merges Waiting for Action, so that I can pick out those that are relevant to our project. Per weekend the total amount varies from 1800 - around 2500 profiles
• On the way I merge where i can all the profiles [where there are consistency in the parents or where there aren't too many complicated anomalies] (the one's where both bio's are on green and cannot be edited). Quite simply because the less of them (an exact tally I can't give, but it might be 50 to 100 on a good day). The fact that others might see that as taking the easy route leaves me cold - because I'm diligent and try my darnest best to merge them correctly, placing eventual anomalies in the comment boxes. This way I do not have to integrate the inevitable messes of bio, now even with two boiler plate formats
• I get very irritated when I see fellow team members trying to merge for example US profiles and then like me end up with either bulky or incomprehensible GEDCOM debri and quite frankly unfamiliar sources, and then get berated by rangers for not doing the final part of the bio integration. So that is also a reason why I avoid the open for edit profiles - I am even as an experienced WikITreer with a lot of mileage not comfortable editing the bios of many US profiles simply because of this unfamiliarity.

Because the second part of your statement ...make bad mergers without exploring deeper into what they are doing ....? ... is exactly my angst that I refer to here (and I'm not only referring to pre-1700 but in most cases to pre-1800 and even pre-1900 profiles:

I have many many times been anxious for profiles to be merged the correct way - into the nearest to correct spelling - not when I'm away but daily. Objections and rejections I can handle; I've learned to take that in my stride and have noticed that once PMs have my trust, that they are more than obliging to help.

I have seen many PMs get disillusioned, irritable and non-responsive though, because they had to deal with so much mail because of the total overload on duplicates. The pre-1700 test did not hinder any duplication of profiles; what does help is at times intense mentoring and behind-the-scenes guidance, and loads of outside of WikiTree email correspondence.

---

With respect to Maggie's comment, very few of the merges I propose get completed by a wandering arborist or other enthusiastic volunteer as soon as the 30 days expire. That's good, because sometimes it takes me a couple of days to get around to re-researching the person to make sure I pick the right profile details, etc. I've gotten the impression that most wandering merge specialists concentrate on proposed merges that have been waiting around for a while since receiving default approval. I guess that impression isn't accurate.

The exception to my general statement is Philip van der Walt, who often completes the merges I proposed for people with Dutch names. ;-)

---

Happens a lot for me. I used to tickle merge proposals to follow up on... but was notified that the merge was completed nearly simultaneously with my reminder to go check on it. Once the Browse Merges feature was added, I just check it to followup on any the auto-merge specialists didn't do (love the phrasing Becky!).

Also, after having comments ignored and merges done the wrong way a few too many times, I took to not proposing a merge between different LNAB profiles until the right one was protected. For any merge I propose, I also try to make sure that datafield info from both profiles is included in the text, so it can easily be found after the fact. I've added a step when I complete a merge myself of opening both profiles to edit view before clicking merge - that way I can check that status selections make it through the merge too (e.g., confidence level for parents). And with the new PPP mechanisms, my post-merge checklist includes not only bio cleanup & review of attached profiles but also re-adding as a PM active PMs from the profile that wasn't PPP (if I can - you have to be a PM to add a PM) & making sure the PPP parents were the right ones.

Cheers,
Liz

---

Now that sounds familiar to me Liz, and also a few tips I have'nt considered implementing yet ...:-) Thanks!

---

Liz: Many of the situations where I encounter a need to merge conflicting LNABs involve profiles that aren't currently within the scope of any project, so the profiles aren't eligible for PPP. This includes, for example, people who immigrated to New England after 1640, people born in New England in the 1600s (and 1700s), and people born in England with descendants who emigrated to America.

And when bad choices are made by the person who completes the merge, that person often is a profile manager who never did a merge before and couldn't figure out how to accept anything other than the default choices they saw when they clicked on the merge proposal (which sometimes includes a merge in the opposite direction from what was proposed).

---

Once more I agree with you Ellen, acute observation!

---

Prior to recent changes, the main feature of PPP was to preserve LNAB that had been agreed upon. Just because it doesn't clearly belong to a project is no reason to leave a merge with the wrong spelling/styling to chance. When a particular project doesn't apply, I add a note at the top of the profile that it was protected to facilitate a merge, cite the Arborists project & sign my name (four tildes), adding that the profile can be unlocked after the merge.

Cheers, Liz