Should only Project Leaders and Coordinators be able to edit the parents of Project-Protected Profiles?

Question

Hi WikiTreers,

Project-Protected Profiles (PPPs) are massively-common ancestors that are frequently duplicated. See http://www.wikitree.com/wiki/Project_protection and http://www.wikitree.com/wiki/Project_protecting_and_merging for more info.

Right now, PPP basically does one thing: it protects the WikiTree ID. It prevents the profile from being merged-away into another profile. This is important because newbies often don't realize that an LNAB is the one that's been decided-upon and bad merges can do a lot of harm.

Otherwise the normal editing rules apply. Any signer of the Honor Code can edit a protected profile, including editing the parents.

Editing the parents is especially troublesome. Project members are frequently having to change them back. We have lost many good genealogists because of their utter frustration at having to do this over and over again. See Jillaine's post here.

So, should we restrict who can edit the parents of a PPP? I'm inclined to think this is a good idea.

We could do this:

1. During a merge, the system would check if the profile being merged-into is PPP. If it is, the system would check if the user doing the merge has a Project Coordinator or Leader badge. If they do not, they would be prevented from editing the parents during the merge. If they attempt to edit the parents, a status message would explain that they need to contact the project. We could prompt a G2G question but we couldn't automatically tag it with the project tag.
2. When editing family members, if a mother or father is being added, replaced, or removed, the system would check if the child's profile is PPP. If it is, the system would check if the user doing the merge has a Project Coordinator or Leader badge. If they do not, they would be prevented from editing the parents. A status message would explain.
3. When editing family members, if an existing person is being added as the child, the system would check if the existing person is PPP, etc.

You can no longer make an existing person a sibling, so I think the above covers all ways to edit parents.

What do you think?

Vote up or down, and post your comments.

Thanks,

Chris

Comments

Yup. PPP has always preserved the LNAB in a merge. Now the non-PPP managers are retained only on the trusted list. For the established/robust profiles this works well. But for others... it's not always a good thing. I checked on a merge this morning & the dropped PMs included the Project Profile! Good thing my followup process includes checking the trusted list :D  I also check that correctly attached family members made it through the merge ok.

Cheers, Liz

---

I have slowly begun to remove all managers including myself (though as research coordinator I can access the profile of course via the Project Profile) from PPP'd profiles that has the Project as active manager as well, That way only the essential LNAB can be changed by the Project, though I imagine the parents can still be manually edited by anyone on the trusted list, or am I wrong? Anyhow, it feels a lot safer knowing that massively merged profiles are now in the hands of the project itself, and not at the mercy of the whims of individual managers.

---

Actually there's another difference between PMs and TLs that isn't listed - a PM can hold up a merge for 30 days just by existing, unless another TL member approves it sooner.  If you give up PM status while staying on the TL, you lose that power.  This is because "orphans" don't need approval even where TL members exist who could give it.

As regards LNABs, yes the restriction can be avoided by creating a blank duplicate and merging the other one into it.  This can be best way to go, especially if there are several existing duplicates that all have the wrong LNAB and you aren't on the TL of any of them.

You're liable to get told off for creating a duplicate, but of course the process is exactly the same as what the system does anyway.

And of course you can't get round a PPP that way.

---

Hi Walt - We do not  know each other so I do not want to "read into" your comment more than it may mean.  I am, however, a bit concerned if you are just removing all the profile managers of all the profiles in whatever project(s) you are coordinating or leading - have you gotten their permission?  Have you notified them ?  or checked to see if they are "active" in managing these profiles ?  or if they are indeed family members/descendants of the people whose profiles they may have created or edited significantly on WikiTree?  I am very aware that any profile manager can remove other managers as part of the "Wiki freedom" we enjoy here but I would always expect it to be done sparingly and at least with notification if not active cooperation (when a manager is still active of course - those who have not contributed for say 6 months or more should probably be removed automatically or at least notified they will be removed and if no response then removed).  I have a number of pre-1700 profiles of my ancestors that either I created or I  helped write biographies for and some of them have been "adopted" by projects.  That's fine and I lay no "claim" to them.  But I would not be happy for the project suddenly to appropriate them and kick me off so I could not make essential changes, especially without any collaboration or notification.  I raise this here but perhaps it's something the Leaders need to discuss too.... What is your opinion and what is  your practice ?  Thanks as always for being the positive contributor I know you to be on our One World Tree.  Chet Snow

---

Chet,

Profile managers being bumped to trusted list of only is one thing that can happen with PPP's profiles. It is mentioned here. Though it's definitely best to give a heads up to PMs that you're doing so, it is not required. If it's something you'd like to revisit, a new thread would be appropriate. 

---

Abby, what is a POP?  Is that an autocorrect error for Project Protected Profile?

As usual, I agree with Chet. Profile Managers should not be dumped at the whim of anyone.  I will remove myself from profiles that I don't have a strong interest in following, but I would be pretty upset if someone just dumped me from a profile I created or adopted.

---

Indeed Abby, thanks for explaining. PPP'd profiles implies:

• That only the LNAB-field is locked
• That everybody can still collaboratively edit and add info according to the rules and the honour code

When I remove managers (including myself) ...

• They are still on the trusted list
• The Project is the only manager that can make changes to the the LNAB-field (in full correspondence)
• The profile is already protected (to a certain standard the LNAB has been validated)

No, I do not ask permission. Thousands of profiles, hundreds if not thousands of managers (many will not even answer or are not active anyway anymore) - it is simply not feasible and it is not necessary - seeing everybody can still work on those profiles wether one is a project member or not, and seeing that nobody "owns" a single profile.

The project is simply the custodian manager ...

---

Sorry, yes, PPP, Kitty. Darn autocorrect :-)

---

Confusing.  But so far as I know, changing LNABs (ie merging away) on PPPs is restricted to Leaders (of any project or none).  PMs PCs and Project Profiles are irrelevant.

The new system also locks parents on PPPs (and all other connections until that gets fixed).  The limitation is to a new "virtual trusted list" consisting of PMs plus all Leaders and PCs.  That would include the Project Profile if installed as PM (though it was also said that PPs weren't supposed to edit - editors should log changes under their own names).

It was argued that this wouldn't be effective unless the PMs were trimmed, and the non-merging of PMs then seemed necessary to prevent them becoming untrimmed.

The concept seems to be that projects completely take over the maintenance of important profiles.  And the difficulty seems to be that most of the profiles people want to protect aren't particularly important.

---

Not so Horace. Yes indeed, only leaders can lock/unlock the LNAB-field, but I as project research coordinator and our team (also consisting of many profile managers wanting to get their amount of profiles under the 5000 mark as well as trusted list "members" and others) dilligently work away sourcing primary records for validation of profiles (LNAB) and organise the bio's of countless profiles left after creation (either by GEDCOM or manually) for others to sort out (arborists & project members) - people who actually care. Although this project (Cape Dutch Colony - and not to confuse it with Dutchness - If you've seen the "Revenant", this is also the kind of characters we find from all over Europe and the globe - only there is no fur trade, but other commodities) has the scope from 1652 to 1806, we also have to deal with profiles from pre-1500 and post-1800. This is exactly the period where there were / are many duplication of profiles because of phonetic spelling, patronymics, various language and cultural backgrounds. And therefore massively merged profiles with loads of active managers who can anyway only do as much as those on the trusted list or anyone else with the right WikiTree certification.

You say the new system also locks the parents - wel I can and should as project coordinator manage to work on parents. It is just worrying (because I'm not the only one doing the merging) that others can also do that. Project Protection (LNAB-field - not the whole profile itself!) does not hamper mergers or collaborative cooperation and the editing and adding of information. The Poject Profile (wikitree-cape-of-good-hope-project@googlegroups.com) can only edit the protected LNAB field after there has been collaborative discussion on why the LNAB should be changed. And then the leader, in this case Abby, will have to do the final unlocking- and or re-locking of the LNAB-field. All other editing is done under trusted list members, project members and the general certified WikiTree public (though this last one I am not so sure of).

What makes profiles important to protect is the variations of LNAB of a certain period in the case of this project, though searching for existing names can be tricky if one is not in the know of the technical intricacies of WikiTree. Profiles are utterly vulnerable even when protected as far as the editing of the contents of the bio etc. goes (because only the LNAB-field gets current protection, and as I understand the parent connections). I do not get where your conclusion that "the difficulty seems that most of the profiles people want to protect aren't particularly important" is based on, as well as your previous conclusion that "projects take over the maintenance of important profiles" ...

Answer 1

When a profile is in a project, usually the project template (box) says '''If you are interested in this profile,
please check out the (project name) '''.

I think Wikitree is a great collaborative site but PPP  (( Project Protected Profiles )) should be protected from making ANY change from a member who is not a project member.

If a member is interested in making changes, he can join the project and follow the rules from the project,. Or he could contact the project leader. This would prevent wrong information and having to make corrections every day or weeks.

.

Comments

Guy, are you saying that if someone has the PGM badge, for example, that they should be able to edit all aspects of a PGM PPP (including parents)? That's a different proposal than what's on the table. But are you suggesting it as an alternative?

If so, I'll quickly respond that IF I still was PGM co-leader, this would move me to check ALL PGM-badged volunteers-- perhaps unbadge them ALL and start from scratch, so that I, as a project leader, would have confidence in the reliability of anyone with a project badge. Implementing this could be even messier than what Chris is proposing...

---

No Jillaine. I also agree with Chris suggestion.  But if possible, I would add the project badge for any change on a PPP.

---

Just a note: Checking for a specific project badge, as opposed to checking for the Coordinator or Leader badge, would be technically difficult or even impossible. That is, it would be hard to restrict anything to project members.

---

Thanks Chris.  I will stay with your suggestion :)

---

I agree Guy.

---

Guy, granting the power to a Project-badged newbie poses the same problem as granting it to a new Profile Manager, who is also a newbie on a merged profile.

Newbies create duplicates. Newbies like to force the data and tree to conform to their own information, despite the long-standing profille status that was previously resolved through a lot of hard work.

Newbies like to become instant Project members. I see newbies remove Project templates, because they don't read the Project category or Project pages to understand, even after they are given a Project badge.

Answer 2

I am in favor of this in light of issues that have caused us to lose great people due to constant frustration.

Answer 3

I disagree. This is supposed to be an open genealogy site to foster participation and collaboration.  To restrict this to select few signals the beginning of a slippery slope. Project Co-ordinators and Leaders are people - as such the are subject to all the selfishness, greed, ownership, power hungry aspects people tend to exhibit.

It's real easy for us to sit here with the powers to be able to say this is right... Place yourself back to the days before you were a Leader... do you still think it would be a good idea? This prevents a person from making changes even though they have the souce documentation. Some leaders swear by specific books, while there is equal documentation to support another viewpoint.

Those tgat are voting positive, if you are a leader, think about the policy from a status of NOT being a leader.

Comments

I think it is wrong to assume that leaders & project coordinators are power hungry....more like pragmatic. Changing the current policy also does not preclude changes to parents. It simply means that more care is taken before potentially uninformed changes are made. The atmosphere of careful collaboration should remain intact.

---

I didn't say we were... I said we are human and subject to human feelings.  I believe that should be factored into the equation.

---

Terri,

I am a former Leader and Project Co-Leader. If this approach were enacted, I would not be able to add parents to a PPP in the Puritan Great Migration project where I currently spend most of my wikitree hours. 

On the one hand, I might find that limitation frustrating. But what I find even MORE frustrating is finding-- after having spent hours researching and cleaning up a profile, and detaching bogus parents, and writing up an analysis that explains why parents are NOT attached-- that someone has come along, completely ignored the analysis and re-attached -- either manually or through a merge due to a GEDCOM upload of duplicates -- the bogus parents-- and most often, without ANY discussion or notation for why they did so. It's that frustration that brings me THIS close to abandoning wikitree.  

So even though my own practice will be affected, I'm willing to give this new limitation a try. I have some other thoughts about this, but I'll write them in a separate answer.

 

---

As a non-leader, I believe I am eminently qualified to "put myself in the shoes of a non-leader"!

I think this is a superlative idea.  If I ever want to contribute something to a protected profile, it is very easy to put the information in a comment on the profile and/or to contact the profile manager and/or project leader.  Despite being a non-leader, I share the concern about protecting the hard work already done from having to be re-done over and over and over and ... and over and over again.

I also think that the project leaders can make a decision to add someone (i.e., Jillaine) to the trusted list of a profile or set of profiles (i.e., all PGM profiles), which should eliminate the addition of impediments to the contributions of those who are well proven to be both conscientious and expert researchers.

---

Gaile, just so you're clear... Chris's proposal would also exclude Trusted List and even Profile Managers from being able to edit parents of PPPs. People would need to be Project Leaders or Project Coordinators to change parental information. (All other aspects of the profile are still editable.)

---

Terri, as I understand this proposed policy change, ANY Leader or Project Coordinator will have this new ability, on ANY PPP profile. There are now dozens of such people with these badges.

The new change would prompt a G2G discussion, which would be the proper collaborative venue.

Also, I can say from being here for many years that I have seen the profiles become much more Open over the years, not more restrictive. So this proposal is simply a small protective shift in the other direction, out of necessity.

---

Terri, there's a question for you below. Look for answer by Philip smith which raises the issue of under what circumstances should profiles be PPPed.

Answer 4

As the project coordinator of one such project where before there was even any project or systemic thought behind, utter chaos reigned, I have the following statements to make:

• It is not about power, leaders, selfishness, greed, ownership etc., though that is not to say that those sentiments / facets cannot play a role
• Our experience is that there is the pre-migration and post-migration determining of LN'sAB. Reflecting back on the LNsAB of the parents. The latter is much more easy than the pre-migration, because of different factors (in the case of the NNS perhaps the other way around - many documents got lost in church fires). The latter would be easier if there were also well versed native speaking sourcerers i.e. Swiss, Danish, French etc.
• Although it will probably always be an issue (duplication through variation - unless through some giant database the name variations are also kept track of) I would as project coordinator absolutely not be able to keep up with the creation of parent profiles because of the sheer numbers of possible profiles (in this scenario I'd like to see the creation of adjudants - helpers or nearest to the leader and the project coordinator).
• What works in the Dutch Cape Colony Project is the collaboration. It is not top down. Also the fact that we try and recognize the contributions of everybody (though I must say that this recent policy to leave out the contributors name after an unsourced fact in a newly created profile, does not help. Even though the facts might be correct but not sourced properly, we now have to discard all data altogether).
• What does not work in the Dutch Cape Colony Project is the optimalisation of the work-flow. We try and have it like a factory floor - say the Ford factory - everyone knows his / her tasks as regard to what is needed, even though every GEDCOM is different and every project member has his / her own quirks and strong points. The end result - the basic frame of a profile should be one with a valid and well sourced baptismal record image preferably with a well sourced transcription. I still have to micro-manage and double check every single profile before sending it off to the project leader for protection. And I have an ever growing pile - now somewhere in the region of 400 that is awaiting final protection. Around 1250 profiles have already been protected.
• It is the duplication of these already validated 1250 profiles that have already been protected, that needs adressing ...!

Comments

I gave and will give everyone in this feed an upvote because I am of the opinion that this is an important issue.

Answer 5

I like this idea for PPP profiles.

I wish there was a way to keep people from merging into the incorrect name.  Or merging two profiles for people that aren't really the same, or where the parents are incorrect, and thus a choice needs to be made.

My concern is that Leaders and Coordinators make mistakes too - albeit FAR less often than the general user base.  I had an experience where a Leader proposed a bad merge, which I had to disapprove. It bears saying that everyone needs to be hyper-vigilant when merging.

I know it isn't exactly what you were asking for feedback on, but I think a "Merge Certification" would be a good idea - one that was required before the user could merge profiles.

Comments

Hi S.,

Two notes:

1. The PPP status does prevent merging into the incorrect LNAB, assuming the the PPP'd LNAB is correct.

2. A merge certification is something that's been discussed before and the possibility is still on the table. It would be quite complicated to implement though. First, just writing quizzes like the Pre-1700 one is very difficult. Second, if it's a quiz like the Pre-1700 it wouldn't really certify much. Third, we probably couldn't require it for all merges, certainly not for yourself or close family duplicates.

Chris

---

Thanks, Chris. It sounds challenging to have such a certification.  Maybe one day....

In the meantime, this proposal seems like an excellent option for PPP profiles!

---

A bit off-topic, but merge certification seems to be a step in the wrong direction.

I have done literally a thousand or so of merges.

Most merge proposals get completely ignored. That is fine, because I monitor the 30 day default approval.

But if every merge of a newbie duplicate had to rely on certification, the merging workload would be double. Especially with Private profiles, where the newbie already typically has not the slightest idea of what is going on in merging, but the newbie is the only one who can complete the merge.

A merge certification requirement would simply prompt the newbie to ignore the previously established tree, and so then simply illegally expand on their own new tree.

---

Can there be a two-step process to address Steven's newbie issue.  Something similar to merges that require both Profile Managers to approve the Merge?

So can the editing of Parents be proposed by a Profile Manager and approved by a Project Coordinator?

Something akin to online transcribers where two people have to agree to the new info being added before the change is implemented?

---

I've run across some oddities on merges that I have proposed, where someone who was not PM manager of either profile rejected the match summarily due to different date estimates.

I sometimes work on completing merges that have been default approved, but unless they are blatantly obvious, same names, dates, manager etc, then if I don't have access to a good source to verify the data before the merge, I don't touch it.  I think arborists and others who work on this should also follow the same notion.  It would save a lot of extra work of re-submitting the merge proposal, which I have had to do sometimes.  Some of the date estimates I come across are pretty far off the reality.

I've also run across the situation where someone has created a whole lineage that is obviously duplicating one already in existence, the oldest of which is PPP.  I cannot propose merges for most of them as that PM has marked them as still living, despite their being a few hundred years old.

Maybe these are problems that should be addressed in a separate question, but I thought I would mention them here first.

Answer 6

So, you already know that I'm generally supportive of this idea. The devil, of course, is in the details of how it's implemented. 

1. Profile managers of PPPs would need to be contacted, and informed of the upcoming change. (In fact, if there's anyway to do it, contact them NOW and send them to this topic thread.)  
2. Related, a protocol for Leaders, Rangers, Project Leaders and Project Coordinators would need to be developed and shared with them ahead of time, so that everyone is brought up to speed on how best to respond to reactions to such a change.
3. "A status message would explain." There needs to be an easy way for a non-Project Leader/Coordinator to be able to contact a Project Leader/Coordinator to request attention be brought to a given profile. For example, here I am, a non-Project Leader/Coordinator, and I want to change the parents of a PPP-- either detach or add/change. How do I go about it? This is where it's going to get messy and careful thought needs to be put into how best to handle all this.
   • Do I post a g2g query, with a particular tag, in order to bring attention and discussion to it? 
   • Do I post a message on the profile, expecting someone is going to find it and respond? 
   • Do I send a private message to some unknown leader/coordinator? 
   • How long should I expect to wait? 
   • What do I do if a leader/coordinator doesn't respond within some given time period? 
4. Related to #3 above, this new policy will place additional burden on existing Project Leads/Coordinators. Before the change is implemented, some level of communication and coordination with Project Leads/Coordinators should be implemented. 
   • Does the project have sufficient bandwidth to respond to parent-editing requests? (Right now, for example, I think the PGM project is lacking leadership.)
   • What process will the project use for tracking such requests?
   • Who, among the project co-leaders/coordinators is in the best position to be the contact person for that project?
   • Does the project need to increase the number of co-leaders/coordinators in order to respond to the increase in traffic? What will it take to do that?

There are probably other issues I haven't yet thought of, but these come to mind now.

 

Comments

Philip is raising a good point. It's been my experience that projects take varied approaches to awarding project badges.  There is certainly a large camp of folks who believe that anyone who expresses interest in a project should get a badge.

When I was leading PGM, I was NOT part of that camp. I made it clear that this was a working project, not just an affinity group, and that people needed to be familiar with the style guidelines, and have some wikitree time under their belt. If they were really new, I'd recommend they spend some time working on immediate family members and near-ancestors, and that if they were still interested in joining the project, to contact me again later. (Now that I think about it, none of those people contacted me later... )

I'm not saying that ALL projects should be like that. Perhaps some are more appropriate as "affinity" groups. But those projects that tend to work on PPPs-- well, I guess I do have an opinion about badge-control there...

 

---

Chris, what will it take for Project Profiles to be added as PMs to at least the PPPs of a given project? I don't think I've EVER seen a PGM project profile as a PM on any PGM profile, much less a PPP'ed one.

If I can help, let me know. (mm... not willing to be PGM leader again, but might be talked into being one of a the PGM project coordinators... if you'd be willing...)

Short of that, I can try to find those PGM PPP profiles where I'm already profile manager and add the PGM project profile as PM, yeah? Now... how do I generate a list of PGM PPP profiles I'm PM of?

---

Mmm... I can't seem to find a project profile for PGM. Is there one? There's nothing listed on its project page...

How does one go about finding project profile pages?

---

Badges should be reserved for active participants in the project. Most of the badge descriptions say "Active participant in the X Project."

Jillaine, regarding Project Account Profiles, not all projects have them yet, but the plan is that all projects should eventually.

There are still some things to work out regarding how these project accounts should be used. One thing I think we know: They should not be used for active editing. Members should be logged-in as themselves and making edits as themselves for proper tracking.

If you see http://www.wikitree.com/wiki/Project_Profiles and http://www.wikitree.com/wiki/Project:Puritan_Great_Migration you'll know about all I know. :-)

---

Jillaine, this is why I said "creating Project Profiles to manage these PPP's was a stroke of genius." - I can give you exact numbers from our own project, but roughly 200 perhaps 250 profiles of the 1250 existing PPPd profiles have been allocated this status. Unfortunately they cannot be batched (with bots either) and one has to be an active manager of ask active managers to add the Project Profile as Manager and also activate it. But like everything else - it will not happen overnight.

I am interested in your question to Chris on the generation of lists with the differents managers though ....

---

Right - Puritan Great Migration ...:-) Understood.

Another topic altogether, but I'd like to know what to do with all the inactive project members .... so much time (even for a research coordinator as myself) is taken up by "paper work" meaning communications ... Is there a policy considering this?

---

Jillaine, Abby's been creating Project Profiles when they've been asked for by the Project Leader.  At the moment there isn't one for the PGM Project but thanks for offering to help!  I'd imagine there will be one set up for it at some point.

---

Jillaine,

We haven't set up a Project Profile for PGM yet. We were kind of leaving it to projects to ask for them at first so we could see what they were able to use them for and how they would work out, which has been very positively. If you would like to help Vic as a Project Coordinator for PGM and start adding profiles to one, I will get it all set up for you two. I am sure she'd appreciate the hand :-) Just let me know!

---

Philip, when I was PGM leader, I would -- about every six months -- review the list of project members. If they hadn't made any wikitree contributions is say, six months, I removed their badge.

Abby and Eowyn, yes, I'm willing to be a PGM project coordinator to help Vic, if she's willing. I know that PGM has recently lost some leadership (again), and Vic is on her own. I've been trying to rope Ellen Smith into being involved; she keeps eluding my grasp... :-)

PGM doesn't have a google group yet. When I was co-leader, I resisted that, wanting to rely on g2g for all group communications, but given all that we're talking about here, I can see the value in having a google group. That's going to take some work to set up, but it could be an opportunity to re-assess current PGM membership and weed out a bunch of folks AND re-enroll others in getting more involved. I haven't seen Vic on this topic thread, so I don't know where she stands on all of this...

---

I was under the impression that Project Profiles were being rolled out slowly and tested. I asked about progress at one time, but I heard no more. The only reason I have not asked for a PGM Project Profile because I didn't realize that we were past testing.

Answer 7

This sounds like a good idea, but I do see drawbacks too. I recently created a profile for the Reverend Billy Graham. I didn't add any family yet. Then a Leader came along and Project Protected the profile. Now if this proposal is adopted, only a Leader or Project Coordinator can add parents for the Reverend.

Comments

I think this proposal forgot to mention the trusted list for individual profiles that are project protected.  I would hope that profile managers and members of the trusted list should be able to make and remove connections.

---

I agree that the profile manager(s) and trusted list should be able to edit profiles they either helped create or with which they are closely associated.  I would not be a "happy camper" if I created an ancestral profile, hopefully with some sources, and then a Leader I do not know came along, put a PPP on it and then I could no longer work on it.

---

I think you may be right, Gaile and Chet. Allowing the PM, and possibly the whole TL, of the merged-into PPP to edit the parents would seem to make sense.

---

Clarification: The only edit that would be restricted (under Chris' proposal) is the editing of the parents of the PPP'ed person.

So if I was profile manager of say, PGM'er Edward Winslow, and his profile became protected, I would be able to edit anything on his page EXCEPT the parents.

---

That is how I understand the proposal, Jillaine.  I think that Chris' comment that we should consider that at least the profile manager(s) should be able to edit a proposal, period, is good.  If a manager becomes obstinate or insists on re-adding clearly-wrong data, then there are other ways to deal with them, not a blanket "do not touch" policy - including for parents names.  I could accept leaving Trusted members out if that's what the wider community wants.

---

I'm sorry but there are situations in the Euroaristo project where if we are allowing PMs and possibly TLs to add/re-add parents, then we might as well not add this extra protection at all.

Particularly cases where the profile might be legendary and the discussion can be the value of one source over another source.

---

John, could this be solved by removing the managers? (Assuming it's just managers who have the ability, not everyone on TL.)

---

Thank you, Chris, for voicing my sentiments before I could turn on my computer (been out raking leaves - 21st Century life wins again!) and read up on this commentary.  Perhaps one corollary to the whole PPP thing is that someone - Leaders, Project Coordinators - ?? - needs to "weed" certain "notorious" profiles of those profile managers who cause problems - always politely and with adequate nice-guy "warnings" as we do not want to cause bad feelings.  Most of those profiles have multiple managers - bump them down to the Trusted List and then reserve parent additions/subtractions to Managers.  Worth a try ?? or Too Hot to Handle?

---

I could definitely remove PMs who appear to be no longer active on Wikitree, but I would hesitate about removing anyone who was still active.  On what grounds would I be doing that, and isn't that behaving as a leader in ways that might be seen as unacceptable?

However probably the profiles where this could be an issue are in the minority and overall I think any added protection is a great idea.

---

John A., did you see Chris 's response elsewhere that there is already an existing policy about limiting numbers of PMs on a project protected profile?

Here is the link:

http://www.wikitree.com/wiki/Project_protection#Management_by_Project

---

Sorry, but Profile Manager and Trusted List status on merged profiles is typically just random. It has no correlation to the quality of tree lineage.

If PM is going to be included in this ability, then the whole endeavor is rather pointless.

Many PMs are random newbies who adopt orphaned profiles. Even PPP profiles get orphaned.

Those adoptive PMs then typically ignore all correspondence.

On the other side of that coin, they are also just as likely to submit to a newbie's bad call on a parent change. Or a newbie will adopt, or otherwise get PM access, in order to twist the tree into their own bit of misinformation.

On the cases like Billy Graham, that is resolved with G2G, where it should be. A notable PPP person without parents should have discussion about those parents, rather than just have some newbie add them with a wrong LNAB, or the wrong parents.

I have seen the wrong parents get added to modern notables. The wrong sibling is attached as the father, who is really the uncle, for example. Much of this sort of thing is just copied from Geni and Ancestry. The misinformation flaws are just as bad in modern notables as they are in deep notables, because people do lousy research, and propagate garbage, on lines that are not their own, and so which they do not personally have any valid information about..

---

I have to agree with Steven here. Besides, many times solving bad mergers and conflated generations involve (in a puzzle-solving fashion) the [dis]/[re]connection of parents. My experience in all these years of WikiTree is that many if not most PMs are either unresponsive or just plain unwilling to respond, and less likely to understand. Once "their" GEDCOMd trees are "in place", they very quickly tend to avoid the complicated matters such as proper sourcing and merging of duplicates.

I tend to avoid making contact with PMs unless I know that they are actively involved. When there is a conflation I will either have a go at it myself, or preferably ask another project member that knows her sources and understands how to fix conflations. I agree with Chris that unless the creation of parents is subjected to the same strict proces as the LNAB itself (i.e. LNAB = protected ; PARENTS = protected), the protection of massively merged profiles will not be complete [in this regard I'd like to add the dis-connection / removal of images and documents from profiles - primary evidence that if I understand it correctly, do not show up on the changes tab].

I would like to suggest the ability to edit parents be given to Project Leaders, Project Coordinators and those project members (capable) appointed by the PLs and PCs.

---

Yes. Awhile back, I adopted dozens of unconnected orphan Notable profiles. And I've created others. I put the Notables Project as manager, and stepped back to Trusted List for myself. All well and good. I connected a bunch of them. I've been reviewing my Watchlist, and found I was denied from adding parents to one of these PPPed profiles. I got on the TL for that one, but there's a lot of them where the project is the only manager, and I'm the only TL member. If I'd have seen this coming, I'd have left myself as manager. If it were adjusted so the Trusted List

As it stands now, there's numerous profiles I created myself which I can no longer attach family members to. And the orphans! Think of the isolated, unconnected orphans! How can those notable cousins ever get connected to the main tree if there's no human user authorized to do the work?

Adjusting it so the Trusted List could make these connections would make my problem go away. I'm sure Abby would be glad not to have to work through a list of 150 or so profiles to change each one.

Pretty please?

---

Indeed, I'm also adding the project profile to protected profiles within our Duch Cape Colony project. As yet only had one instance where the three parent profiles had to be merged first before a merge of the a duplicate into the protected project profile managed profile {PPPmP} could take place.

Though it is very reassuring that parent connections are more secure now and protected from un-challenged de-connection, it will become very soon a process problem that even I as project coordinator logging in as project will not be able to solve when confronted with multiple parent profiles having to be merged, some with different spelling of the LN'sAB.

Of course ultimately a leader as Abby of Bea will be able to help, but I would like to have an answer to this dillemma or at least have a clear-cut procedure to follow ....

Answer 8

Having come across some EuroAristo profiles occasionally that are PPP'd and yet dubious at best if not entirely mythical (and having a baker's dozen profile managers) I can see on the one hand that more control over these profiles would be very helpful. On the other hand, progress on these profiles is so slow now that I can't imagine how much would get done given how much more work would be generated for the project leaders were this policy implemented.

I'd be generally in favor if we could agree only to protect well researched profiles which cannot truthfully be said about many EuroAristo profiles.

Comments

I think in the past, there has been a tendency to PPP many profiles, and for often good reasons, but as you say, there are some that have been given that status where the names might not have been discussed etc etc.

At this stage I think the best policy is to keep them as PPP but gradually as merges take place or profiles are updated then make sure they are well researched.

---

Helmet raises an issue that I also raised and that I haven't seen addressed by Chris-- namely the impact on project leaders/coordinators if this gets implemented.  I think each project should get the chance to identify someone who would be responsible for processing such requests. Or a system like the Rangers have of taking turns.

Project profiles were implemented after I stopped being a project leader. What happens when you private-message a project profile? Where does that message go? Or would it be better to have requests be posted as public messages on the project profile page so that there is a public record?

In any case, this handling of parental-editing requests needs to be figured out and supported before such a change gets made... IMHO, of course...

---

Jillaine, I've written somewhere else but I'll write again,  - I think any extra time spent by project leaders/coordinators in changing parents, will be totally offset by the current time spent in correcting changes to parents for which there are no adequate sources.

I would also think that the leader should expect that if someone wanted to change/add/delete parents they would also provide the source/s for that change making the decision that much easier.

---

I concur, John, that's why I'm willing to support this new policy.

Answer 9

I think this is a great idea.   I think there are a half dozen profiles on my watchlist that clearly say "Parents Unverified" with an explanation of why and who, etc.   At least once a week a new member comes in an puts parents on that profile.   I am just tired of pushing that rock up the hill.

Could there be 2 types of PPP?   One that protects the parents and one that invites collaboration?

Comments

Thanks, Robin. What you're talking about is exactly why this is being considered.

Regarding two types of PPP, that would be very complicated.

---

Robin, could you say more what's behind your suggestion for a second type of PPP that invites collaboration? How would the change Chris is proposing disinvite collaboration?

Answer 10

I think this is a great idea, but (much like Jillaine) I foresee a number of issues in implementing it. This change should be made, but there will be some challenges in the early days.

First, it's clear that this change will add to the workload burden placed on project leaders and coordinators. (And, as Jillaine pointed out, it will create a need for better communications protocols within projects.)

Second, while this is needed in projects like Euroaristo and Puritan Great Migration, where there is an acutely felt need for this change, it may not be such a positive change in many other projects. The Euroaristo and PGM projects have what Chris called "massively common" ancestors who are featured in widely disseminated, but disproven, genealogies that people eagerly contribute to Wikitree on a frequent basis. Preventing changes of the parents on those PPP-ed profiles would be hugely beneficial. I'm active in PGM, so I know that the need is great. I predict somewhat less positive results in the New Netherland Project where I'm also active. That project also has some massively common ancestors. However, because the New Netherland project has heavily focused on standardizing LNABs, many New Netherland profiles have received PPP status (to facilitate getting duplicates merged to the best LNAB) without first getting decent genealogical information. In that project, this change could impede progress because it would limit contributors' ability to remove incorrect parents from a profile or add newly documented parents to a profile. I am not as familiar with projects like Notables, but it appears to me that they typically want people to add parents to many of their PPP profiles, so this could require them to rethink the use of PPP.

Comments

Very good points, cousin Smith. :-)

Re NNS, my sense is that its current process already discourages parental editing by anyone not heavily involved in the project. Its project tags scare the $&@%# out of me and I generally stay away from such profiles, limiting my time there to only my direct ancestors. And even then I do not feel at all encouraged to make any relationship changes.

That said, I do worry that this new policy will burden the already overly burdened NNS project coordinator. Already it takes him months to respond to LNAB changes, PPP requests and merge completions. Add parental editing requests? Yikes.

---

Speaking as the Project Coordinator of the New Netherland Settlers Project, I am all in favor of this idea, as long as it is implemented as advertised - that is, restricted to Leaders and Project Coordinators, and absolutely not to given to whatever random PMs.

There are a small handful of people who will need a new Project Coordinator badge, if it interferes with their very good work of correcting bad parental relationships.

I am all in favor of nominating several new people for that badge in NNS, to simply address the burden issue. To me, these people should have no objection to getting the badge. They have proven to do go work over the years, and they can certainly be trusted with the tree as much as they are now.

Jillaine, NNS is really not all that scary. I have seen many people get the hang of it, once they pass the learning curve, and who are now very good contributors to the Project.

But it desparately needed the PPP system to prevent it from being a total disaster of eager mis-contribution by hundreds of people who all have their own individual variants of the massively shared and inter-related tree of this small bit of land which became the capital of the world for the next few hundreds of years.

Answer 11

I'm going to look at this from a different angle - what I hear you asking is for Admins and Project Leads/Coordinators to take on additional responsibilities and be prepared to respond to requests to modify the profiles within their area of responsibility. I think this will work, but want to make sure that we have the proper infrastructure in place to channel these requests appropriately. While I'm not completely convinced that we'll receive a flood of requests overnight on this, I'm sure they'll start to trickle in once this change is made. So thinking this through, how exactly will someone request this change? Private message to the profile owner? This is often not a leader, but just the person who initiated the profile. This defeats the purpose stated at the top of the thread. And if we go by the letter of the thread, the original profile owner (if not a leader) would also not be able to make these changes - or are we saying leaders, plus the original profile owner? Are we going to make sure that all PPP profiles have the project email attached as owner? That's a much bigger change and I doubt we want to try to put this in place, as each project has its own process for this.

Regardless, I'm in favor of this, but want to make sure that we have a way for the appropriate person(s) to be contacted and that we're not accidentally sending these updates to someone we don't intend for them to go or to a single person or group who becomes overwhelmed.

Comments

Scott speaks my mind on this. I raised this issue earlier on and have not yet seen it addressed. Thanks, Scott, for shining additional light on this.

---

Re: project profiles, the email goes to a Google group. Usually it is just Leaders and Coordinators on it (I think I need to add you to the Notables one, Scott) to watch activity, but for some it's the whole project's communication list so many members are on it. Just to give perspective. I think using those profiles as managers would definitely help with the "who to contact" issue.

---

Ah - I see the more involved discussion above on this very same topic. Good to hear I'm not the only one. I'll defer further comments to the above thread. Thanks!

---

I think the most reasonable thing is to simply go to G2G from the PPP profile.

It makes little sense to me to complicate and burden Leaders and Project Coordinators with private messages on established lineages. The messages should always be highly public.

If a newbie tries to make a parental change, then a pop-up notice should simply say two things:

1) Look in the upper right corner of the profile to see if there is a G2G discusssion which addresses the parental issue, or browse any existing G2G to see if the topic has been discussed already

2) Start a new G2G discussion from the PPP profile about the parents. Please use the proper Project Tag so that all interested followers will be able to contribute to your question

This will allow the issue to be addressed in a single public place. All  PPP profiles with controversial parents should eventually have this.

Maybe as Chris suggested earlier, that G2G process could be simply automated in some way, although I would not like to see duplicate G2Gs every time some newbie came along and tried to change parents.

So if the PPP profile has any existing G2G already linked, maybe it could just abort the new G2G initiation, and instead simply display the message above?

And if no linked G2G already, then it would initate a new G2G, with a similar or alternate message? Either way, whatever works. As long as the implied direction is clearly to take it to G2G.

---

Actually, Scott, I'm glad you called this out to a separate answer; my mention of it was one of several issues. And I think it deserves an area of its own.

I *love* Steven's suggestion for encouraging people to go to g2g. I, too, prefer the g2g approach (always have with PGM controversies). It documents the issue in a public place, it invites people to explore the issue, it creates a record that remains attached to and accessible from the profile in question.

---

I also really like the idea of a related g2g post directly on the profile discussing parental issues.  That would be very helpful.  Great idea Steven.

---

I'd support the idea of G2G as the place to go when you want to submit specific changes to a PPP profile. It will make things more interesting around here for awhile as we adjust to that approach, but the discussion has generally been valuable on the forums and I really like the concept of a public and recorded conversation and decision on the approach, even if we don't reach an overwhelming majority, at least we can all agree that we were able to get our 2 cents in.

So the only other question would be should we consider updating the PPP image to reflect this information in some manner, and even more interesting, should there be an extra button to click to take you direct to G2G with a pre-filled question that will make it easier to keep the categories and structure of these messages consistent to the group. I know we can't program around everything, but if you don't ask - you don't receive.

Answer 12

The focus seems to be on specific projects... the NNS, the Euro-Ariso, Gateway Ancestors etc...

BUT -One Name Stidies are Projectsvthat can PPP and so us the Cenetery Project and The Various other projects.  

I'm in the Cemetery Project, I just finished an old cenetery and PPP every profile.  Now another person discovers tgeir Great Grandfather is buried in that cenetery... that person is now not  able to add the rest of their family to the Great Grandfather.. guess yhey will end up creating a new duplicate profile because he/she would want to be the manager of their directfamilt ancestral line.

What about the Global Reunion Project... here again this could affent millions of profiles..

Perhaps a time constriction could be used.. say this applisvfor profiles 300 years old?
It woul

Comments

Just so it's clear... my answer was an example, I did not just fibish an old cemetery nor did I PPP any profiles..

---

Terri, please see http://www.wikitree.com/wiki/Project_protecting_and_merging

We will need to review these guidelines for PPP with all Leaders who have the power to designate them.

Fitting within a project is only one requirement for setting a PPP. The profile must also be 200 years old or fit the guidelines for notability.

---

Terri,

You raise an issue that I think needs addressing. How do other projects, like those Terri mentions, use PPP? (I can't quite see why grandfather in the above example would be PPP'ed by the cemetery project.)

Also it's my understanding that Chris's proposal does not affect the *children* of PPPs, just the parents.  So in Terri's example above, I could still come along and add children to grandpa.

---

To emphasize, these sorts of projects should not be PPP'ing all the profiles. Only profiles that are massively-merged and controversial should be PPP'd. If this isn't understood we need to go over it with Leaders.

---

On any properly PPPd profile, new parents should be discussed. The discussion can simply be, "hey, I need to add parents, here is my source."

It is just as easy for a person to start a G2G as it is to create a parent. So there should be a prompt that somewhat clearly directs the would-be parental creator to go to G2G about it, directly from the child profile.

This just seems ideal and logical to me.

It would also allow an opportunity for followers of the project tag to monitor each ancestor creation in turn, and then apply any further PPP on those following new ancestors, as needed.

This would be the letter and spirit of ancestor collaboration in action, rather than what it is now, which is just people creating whatever they create, and then requiring project members etc.to follow along behind at some later time when they stumble upon it, and so then try to validate, adjust, correct, or otherwise accept whatever has been created without any collaboration whatsoever.

---

One technical hurdle to easy G2G collaboration is that we can't automatically add the proper tag. The member has to figure out which project tag to use and has to enter it themselves. Maybe we should think about every project template including the tag. That would at least put the tag on the profile in a place that's easy to spot.

---

Great idea, Chris-- incorporating the project tag into the template...

---

Chris, I think it would be a good idea for you to create a new thread about the purpose of PPPs. You've said two different but overlapping things about them. In your opening message you said that PPPs :

"are massively-common ancestors that are frequently duplicated."

And just above a few responses, you said PPP should only be used on profiles that:

"are massively-merged and controversial."

We also know that people are using PPP to protect the LNAB from being changed, even if the ancestor is neither massively common, controversial, nor frequently/massively duplicated.

In any case, a revisit and discussion about the purpose of PPPs appears to be in order.

 

---

The nuts and bolts about the why of PPP are explained here.

1) Must be in a Project

2) Must be

  2a) 200 years old, or

  2b) Notable

3) Must be lowest number ID (on the *correct* LNAB)

 

What it does:

1) notifies that profile is in a Project, and so higher standards about editing apply

2) Protects LNAB from being merged away

 

What it does not do:

It does not prevent anyone from adding a spouse, parent or child.

So this last item will need revision, per this new programming change.

Chris' statements about "massively common" and "controversial" just seem to me to follow as a consequence of the fact that the profile in question belongs in a Project. I don't ask for PPP of all profiles that *could* belong in a Project. But if they have merge or controversy issues, then certainly they belong in a Project for proper handling, and so a PPP is appropriate, even if the target profile by the definition above is sketchy or incomplete.

Jillaine, are you thinking that the definition needs to be more explict in some way, beyond those three existing requirements above? I don't really see the imperative immediate need, but maybe a new G2G should follow for discussion of revision of that page, as a result of this programming change.

---

Perhaps a new thread isn't required? Just seems like there is not practical alignment or shared understanding of the implementation of the PPP policy.

---

Thousands of profiles have been lnabbed (not by me) to conform to naming conventions.

This is done to give the search system a chance of finding them, to forestall duplicates.

Having conformed the LNAB, you don't want somebody to merge it into a non-conforming LNAB.  So you lock it.

If you aren't supposed to lock it, what do you do?  What you need then is another flag that's just like the Locked flag, but has a different name and comes under a different help page.  But this is getting silly.

---

RJ,

But profiles that have controversial LNABs *do* qualify for PPP. That isn't in the "nuts and bolts" section of the help page (probably should be), but it is in Chris' comments above.

---

Jillaine, see how the Help page does discuss identifying the *correct* LNAB, when searching for the lowest number match.

That's why I included that bit as an abbreviated parenthetical note in requirement 3) when I compiled my brief outline above.

So I think that covers the "controversial" aspect.

---

That covers most European medievals then, since they're all vulnerable on the LNAB front.  Even the fictitious ones.

But the help file then says that PPPs will be project-managed.  This is crucial, because if it's done, then it's desirable that PMs should have editing rights, but if it isn't, then it isn't.

 

---

RJ, by "project-managed", I take you to mean that a Poject Member should be Profile Manager on the profile.

We now have a new type of account profile, the Poject Account Profiles, for top-level projects. Here is the Project Account Profile for Euroaristo, European Aristocrats Project WikiTree.

I think the goal on these Project Account Profiles is for them to become managers of most or all of the Project profiles. I add them onto Project Profiles that I am managing. Doing this is generally in the hands of the Project Leaders, but the process is still being worked out on each project.

Here is the Leaders Help page on Project Profiles.This process is brand new, and under experimentation and development, but it directly relates to this discussion about PPP.

Answer 13

I'm getting lot's of not nice messafes from my post.  The fact I'm getting these emails proves my point that we are all human and subject to human feelings that may cause us to react in a negative light. Please try to restrain your anger.

1.  I really think this is a good idea for specific profiles.. not necessarily all profiles that would techinally qualify.

2.  I am bringing up altenate viewpoints on purpose to hopefully get people to voice more opinions and keep the discussion going.

3. The more angles that are discussed will provude better information for Chris to make a decision.

4.  Honestly, since I'm a Leader, this would not affect me either way...  except to make me not have to go back and constantly correct the Cunningham Clan.

So Please stop with the "not nice" or less than professional private messages.

I don't believe Chris wants a bunch of "Yes" people.. I believe he wants constructive discussion.  Sometimes I agree with Chris, sometimes I don't. .. I'm not a "Yes"person.  I always respect Chris and tge decisions he makes... and I will alwayd try to bring up alternative scenarios for him to consider.

Comments

Yes RJ, that is a bit more color on the same quagmire I outlined above with Smith.

In your example, there is no choice for the merge order at all. It must be Ziggy-5 as the final destination, regardless of whatever has a PPP or not, because Ziggy-5 is the lowest number match with the exact same spelling. The system does not allow merge into any higher number.

But since Ziggy-5 is not the original parent of the PPP child, then It does seem that a Leader must somehow complete the merge, or disconnect the relationship, which is a troublesome and awkward and distateful way to resolve what amounts to a bad bit of software programming.

So hopefully the fix can be built in to the program to accommodate this situation before this change goes live.

On the other hand, their is no guarantee that the lowest number match of the spelling is indeed the same person. For example, Ziggy-5 may perhaps be an infant sibling of the same name who died young. So he is an infant uncle of the PPP child.

But if the system allows an automatic merge override in this case, there is a possibility of a random new person merging away the correct parent into the wrong profile, simply because the grandparents are the same, and the name is the same.

I think the technical solution that I would like to see in such a case is to impose an automatic merge block on the PPP child, until a Leader completes the parent merge successfully..

In other words, whenever a merge proposal into a a PPP child profile has a conflicting parent of any kind, then merge completion is totally locked, similar to how it works now if both profiles have PPP. Nobody can complete the merge until one of the PPPs is removed.

The parent merge completion would also be locked (except for Leaders), per the new program rule, if the result would be a parent swap.

So this additional child PPP lock that I am proposing would then allow some extra time for project member and Leaders to assess the situation, and resolve the parents, through G2G or other alerts for Leader attention on the parents to resolve them in the correct way first..

Frankly, I would like to see that child lock (whenever parents differ)  be imposed now in any case, on all merges, PPP or not. That would stop the awful practice of people disconnecting all the extra parents every time they complete a descendant merge first.

This single programming fix would be a blessing to the WikiTree, because it would train people into the best practice of resolving the oldest ancestors first.

---

Oh, I read you wrong, RJ. You said Ziggy-17 has the correct parents.

So Ziggy-17 and Ziggy-5 are the same child. Ziggy-5 gets a PPP.

NOW, Ziggy-17 cannot be merged into Ziggy-5, because the result is an illegal ADD of parents on to Ziggy-5 PPP.

I need to re-think this scenario a bit.

---

Okay RJ, who says Ziggy-17 has the correct parents?

There is no PPP on Ziggy-17, so the parents are implicitly questionable.

Somebody puts a PPP on Ziggy-5, because the authoritative source says there are no known parents for this individual.

This is exactly the kind of block that we we want to occur. If a Leader places a PPP on Ziggy-5, or swaps it over from Ziggy-17, then at the same time the Leader needs to adjust the parental attachments to make it right.

I think this is fine. So then take it to G2G,or to a Leader to resolve. The purpose is to prevent random and frequent and uncontrolled single contributions from altering parents on any PPP profile, without discussion.

As lower number loose matches pop up into various projects as matches, then it just becomes good practice for Leaders who place PPP on them to make sure that the parental path is also clear as needed. I don't think it is such a burden. Why would the Leader put a PPP if the Leader does not see the rest of the tree in the match that is original?

Leaders only place PPP on things they are actively working to resolve, so parental integrity is simply an additional checkpoint for them to look at when doing this task.

---

Clearly there are some very different conceptions of what PPPs are for, and indeed, what projects are for.

---

In the PGM project we wouldn't put a PPP on Ziggy-5 JUST because it's the lowest LNAB. in fact it's usually the case that it's the better researched profile that gets protected. (I've seen this in NNS too.) When a lower LNAB gets found, we need to contact a leader anyway to complete the merge. With the new system we'd ask the leader to complete the parental link change at the same time, so there would be no additional request needed to be made.

Steven, the scenario you're describing is different from what RJ is describing. He already pointed out that -5 is an unsourced, unparented  piece of junk from an early gedcom upload and that -17 is a well documented profile with documented parents that came along later.

IF -5 had been PPP'ed (and I don't know why it would have been given its condition) intervention would be required to complete the merge of the well documented with parents into the poorly documented but PPP'ed lower LNAB, anyway. Frankly I have no problem with that. RJ, the amount of heart breaking, frustrating reconnects of bad parental info makes this hassle worth it to me for PPPs.

This overall discussion *has* raised the need to revisit the purpose and use of PPPs. And also the relationship of projects and PPPs. RJ, where are you seeing the biggest differences or discrepancies? I think it's good that both you and Terri are raising issues that need to be talked about to make sure implementation is thought through carefully.

---

Well, in practical PPP consideration, I always ignore the condition of the profile in every other aspect, because the LNAB is the only relevant datum for PPP..

So if Ziggy-17 and Ziggy-5 are known matches at the same time, it only makes sense to PPP Ziggy-5, because in the end, Ziggy-5 will be the surviving profile, in the preferred way that WikiTree is technically designed.

A primary directive in WikiTree is to minimize the number of redirects. So, both Ziggy17 and Ziggie-2 should be merged into Ziggy-5. This will instantly convert Ziggy-5 into the well-researched and connected profile. We should avoid the loss of the lower number Ziggy-5 by its being merged away into Ziggie-2, for example, thus resulting in an eventual merge with Ziggy-17 as the final LNAB. One main reason for this is because later somebody will find Ziggy-10, which turns out to be for the same person, and so then we are faced with a situation of multiple redirects.

So therefore best practice is always to only PPP the lowest number match of the exact same LNAB whenever possible, regardless of the state of the rest of the profile. See the Help FAQ on this about redirects.

But in NNS, we usually have different spellings, so the decision about PPP usually involves the spelling choice, and not the match number level.

Also in NNS, the older, lower number matches tend to be disconnected and scattered, and so they will only pop up at a later time as a match, which forces us to do a PPP swap, and hence an unfortunate multiple redirect because a merge is always impossible into a higher number with the same spelling and capitalization.

---

I'll give an example of a good reason why a poor quality profile might get PPP designation. In the New Netherland Settlers project, we might discover that this same person was represented by profiles Ziggy-5, Ziggy-17, Van_Ziggy-1, Vanziggy-2, Jansz-9, Jansen-47, Janse-14, Sigij-1, and Zigy-1. Additionally, some of these profiles would have a father profile attached, with profile IDs Ziggy-6, Van_Ziggy-1, Vanziggy-1, Arentsz-5, Arentsen-12, Arentsen-19, Sigij-2, and Zigy-2. The project's goal would not be to protect the ID with the best-written profile, but rather to protect the ID with the best LNAB and the lowest number for that ID, then ensure that all of the duplicates get merged to that ID. Discussion might lead to consensus that Arentsz-5 is the best ID for the father (who was born in a time and place where patronymics predominated) and that Ziggy-5 is the best ID for the son (because the father is found to have adopted the family name of Ziggy before this child was born). PPP would be applied to those selected profiles (even if they weren't particularly good), and the profiles might continue to be pretty pathetic through the often-slow process of getting all those other profiles merged (also, to avoid disconnecting families, the project would wait for the father profiles to be merged before starting the merges for the son's profiles).

Added: Steven types faster... ;-)

---

I am trying to respond to Brown-8212 but I can not find the entry that was emailed to me. It said, 

"Chris will explain it in his new post, but the managers of merged in profiles will not be auto-added as managers of the PPP'd profile."

I just wanted to ask by what criteria will PM's be added. One profile which recently blew up of mine, is a prime example of all of that which is being discussed...right down the the current manager, other than myself has not been on the profile to make changes since the profile was created 4 years ago through an GEDCOM Import.. Who knows, it may have been an orphan in their database. So the criteria of picking PM's I would imagine will be very important as It will be their responsibility, I assume, to ready the ready the profile for PPP status. I have been doing that for this particular profile, because this will be the 2nd time I have done it. Being one who was responsible for controlling man-hours through out my life, I would expect WT productivity ratio would be interesting.   Thanks.

 

---

Jim you might want to edit your post. It's littered with typos. (Tapping from a phone or pad? I generation wontons of errors myself that way.)

I don't think Chris has posted the announcement yet. Hopefully it will address your concerns.

---

Thanks Jillian. OMG. I had no idea. It's the combination my brand new keyboard sometimes allows keys to stick, plus, the auto correction of words and also me trying to type like a professional typist with two fingers...well four!:). It took me a while to even figure out what I was trying to say in a few places

Thanks again!

Answer 14

What about Gedcom imports?

Comments

I would just like to state why I think restricting the changing of parents is important to me. I have recently asked for project protection on several profiles because several profiles are different people with the same name. One group of 5 men same name. 5 generations scrambled. Spouses , sibblings , parents. We all have at least one bunch like this. Each time a new person comes on the scene... duplicates , edits , messes. I do not believe this idea limits collaboration , I think it actually makes it possible. It cuts down on the " lone wolf". In that it forces communication. I think wikitree can not survive if it is in a constant state of " repairitis". The concept of co operation and collaboration and everyone can participate is great. BUT the reality is this concept promotes confussion. When a profile is well sourced it is well sourced. Many changes to sources just for the sake of changing are damaging. I don't think , at least on my part it about control or badges or recognition. I would love to have all my profiles accurate as possible and complete. I really think this discussion is great.  I think that this is great for the health of the tree. It is unfortunate that there will have to be limits set on a wiki. But there either has to be limits or confussion . Thank to everyone for their input. I have learned from this discussion.

---

Make them stop. Please.

But seriously, Gedcom profiles have no PPP, so where do you see them coming in to this, Terri?

---

I really don't know. I have never used a gedcom. This is why I'm asking. Will a person importing a gecom be able to add to a PPP?  In other words will using a gedcom bypass the control Chris wants to implement?  

There might not be any issues.. but I would like this addresses just in case there is an issue.

---

Good point, Terri.

When a GEDCOM is uploaded, the next step is the matching process-- comparing entries in the gedcom to existing profiles. If one of those gedcom entries matches a PPP profile, the new system would have to apply to that as well. Will it, Chris? And how?

Answer 15

I am in favor of the proposal.  I know there will be stumbles and burps, but currently, having a PPP just protect the LNAB is not enough.

Answer 16

When a merge is done, or an LNAB gets changed, do the children of the merged-away profile get "reparented" within the meaning of the Act?

(ie what happens if the merged-away profile isn't PPP - can't be - but one of its children is?  What if it's a bad merge?)

Comments

Ooh. Good question, RJ. Do you mean this?:

Zippy-17 is getting merged with Zippy-5 (neither PPP'd) who is the parent of PPP'ed Zippy-4. Technically that is a change of parents of a PPP which should kick in the new system. Chris, how would your solution address this?

RJ, I'm not sure what the bad merge reference has to do with it. Bad merges are bad with or without the new system. Under the new system, if the above scenario does activate the lock, that's an opportunity to check for a bad merge before it happens. Please say more if I'm  missing your point.

---

The parent of Zippy-4 is Zippy-17 before and Zippy-5 after, so technically it could be seen as a change of parent - but hopefully they both represent the same person, and they will have been combined.  So there shouldn't be any need to worry.

But if it's a bad merge, the damage to Zippy-4 is more serious.

Answer 17

I Voted No as I am quite good at discerning between Sr., Jr., III, IV, V. Dorcas Pain(Pain-132) had many marriages & I added so that she also appears as Vickery. This is not the only site that has these specific problems, examples: ancestry.com , geni.com .                                        Thank You Kindly, John P Vickery IV

Answer 18

Chris,

You have written - Project-Protected Profiles (PPPs) are massively-common ancestors that - this statement is not true for many profiles.

An example - Dewey Volley Bromley  - Dewey has been made PPP - he also is unconnected but the information for his parents is known, just not entered - they are listed in his profile.

So while Dewey is important - a military veteran that died in service - he is not a common ancestor nor is there any question as to his parents - so in this case I think that anyone that wishes to take the time to add his parents should be encouraged to do so.  

A rule that would require that Project Leaders and Coordinators be the only ones that could edit parents would prevent me as the profile manager who created the profile from adding his parents - that seems wrong in this case.

Comments

Philip, why is this Dewey profile protected?

---

Jillaine,

I did not protect the profile - so I can not answer - many profiles for military are protected - perhaps someone else can explain the process.

Just so no one will think there is only one profile like Dewey here are two more - same case - unconnected, PPP and I am the manager that created the profiles - I did not add the PPP and the project involved does not show.

James Henry Allyn

Charles R. Auer

---

I just looked at the changes log. Terri Rick PPP'ed all three just a month ago. Hey Terri! What was the impetus behind PPP'ing these?

---

This is what we do in the Military Projects.. we protect the profile to prevent merging away.. This is how the projects were set up. When I was correcting the WWIICategories.. I did protect a few profiles.. Which is standard for our project. The two you listed above were KIA... as the template shows.. KIA is covered by the Roll of Honor Project.  Sonce the PM was a leader.. this could easily be changed.

---

Got it; thanks, Terri.

---

And again for this sub-thread answer, here is the Leaders help page for the why of Project protecting and merging.

I outlined the points of that page above, but the link again here is helpful for clarity of the discussion.

Answer 19

Chris seems to be saying that only a small number of special profiles should be PPP.

But obviously, Leaders who want to use PPP to protect their work are going to PPP all their work.

If they don't, the rest will still be vulnerable and they're just going to feel that nothing much has been achieved and the problem remains.

You can't have it both ways.

Comments

I'm really trying to understand what problem you're trying to point out, RJ. Are you concerned that Leaders will abuse their powers? If they're going to do that, they'll do it with or without this new system right?

Or are you saying that this new system will give them even greater opportunity to abuse their powers? Certainly there are avenues for seeking redress for any "bad behavior" here-- whether it's with a Leader or anyone else.

And I'm not sure what you mean by "the rest will still be vulnerable" -- the rest of what? And "you can't have it both ways."  What are the two ways you're saying are in conflict with each other? What's the problem that remains?

I really do want to uncover the problem your concerned about because as my original response indicated: the devil will be in the details of implementation so we need to think this through carefully.  

(In my non genealogy work, we use-- with ourselves and our clients-- a tool that encourages us to think through and plan for challenges before implementing a new piece of work.)

---

Chris says PPP is only for profiles that are massively-merged and controversial.  But this limitation seems to make the plan a lot less useful than many people expect.

Profiles that don't qualify for PPP will still get screwed up and nobody will be happy until something else is done.

---

Once more for clarity the Leaders help page about crtieria for which profiles get PPP Project protecting.

Chris' comments about "massively-merged and controversial" is just another way of generalizing about profiles that are Project candidates, and thus PPP candidates.

As far as other profiles not getting protected from getting screwed up, and thus some people having something to not be happy about... well, it's a wiki.

---

Almost all profiles are project candidates.

Anybody who's dead and buried can be in Cemeteries and anybody with a surname can be in One Name Studies.

---

RJ, Chris specifically stated above that the Cemeteries and One Name Studies are not the type of projects that are appropriate to have PPP as a tool.

Common sense tells me that something like cemeteries and surnames encapsulates the entire 7 billion population of the Earth, and their billions of ancestors as well, so accounting for all potential profile subjects of those projects is simply too broad for the use of PPP to make any sense on any random subsets of them.

I would also be rather annoyed if somebody was using that broad classification of a *project* to ask a Leader to waste their valuable time putting PPP on all residents of any particular one of what are many thousands of cemeteries, or any one of millions of surnames. It just defies organizational logic.

On the other hand, you will have certain very notable project sub-sets that are indeed worthy of PPP on all subjects. For example, the original Union Civil War soldiers buried at Arlington who actually died in the conflict through 1865. They were just common soldiers, but their bodies were hunted up by northern government teams who tracked them down in their hasty shallow graves all over the South, and then relocated them to Arlington, as I understand it. The process was very intensive, and documented, relying largely on interviews of the locals who had hastily buried them on the battlefields where they fell.

So we just have to use common sense on these things about what applies.

---

I concur with you Steven that just because something is in a project doesn't mean it warrants a PPP.

I do wonder, though, what would be the purpose of PPP'ing the "original" Civil War soldiers buried at Arlington? They're probably not "massively common ancestors" and there probably isn't much that's controversial about them, and they're less likely to have LNAB problems because surname spelling started settling down around that time.

(That said, thanks for the bit of history; I hadn't known that before.)

---

Thanks Jillaine, it is a fascinating little bit of history that I had picked up from somewhere. It struck me at the time how *modern* the investigation seemed.

The reason for the PPP would be satisfied by the Help page condition

1) notifies that profile is in a Project, and so higher standards about editing apply

It would be based on the idea of a project locating from government archives the original list of recovered remains, and all the inclusive detail about each of them. So it is sort of like a mini-notability standard for a sub-project.

The full list of millions of later Arlington burials would not apply, but instead just the original group of KIAs who were consecrated in this special way on that former front lawn that was confiscated from General Lee for the purpose. It may not be the best case, or perhaps too huge of a list to be practical, but I was just pondering a likely cemeteries example that would counter my first argument that cemetery burials were usually too broad in scope for such a thing. But my Arlington example would surely fail on the 200 year rule, so I should have found an earlier cemetery example.

Similar is the Mayflower passengers. They were just ordinary people, on one boat. But that one boat happens to have been the first to succeed, so it gets lots of attention. Nobody cares much about who was on the boat that arrived a few years or so later, although they are also from the same generation of massively-shared ancestors.

Similar cases might be passengers on the Titanic, for example. Just one cruise ship voyage among many thousands. The key thing is that the event is what is highly notable, although the people in the event were largely just ordinary folks. That also fails the 200 year rule, so I don't know how that Project treats them for PPP, other than the rich and famous notables who were on board.

---

I think this would best be applied to some specific projects first, i.e. PGM and EuroAristo, but this would require knowing *which* project a PPP profile belongs to. Perhaps we can determine this through the templates or categories in the biography, and implement the rule that if a profile (or the profiles we are trying to associate with this profile as parent, spouse, or child) has a PGM template, then the person making the association should be a leader or project coordinator from the PGM project. We could also validate that all of the PPP profiles in a project have the proper templates and categories, and would have to have some mapping between categories and projects (i.e. 'House of X' categories for EuroAristo). Or - enhance the PPP status/checkbox to tell us *which* project the profile belongs to.

For my own project specifically, Notables, I don't think there's much controversy or rework or massively common ancestors which apply to that project, so I'm fine with letting the profile managers mange the profiles they have taken responsibility for, and allowing the normal relationship editing. The generic Notables ID is very helpful for monitoring profiles managed by the project, every project should have something similar.

So - upvote - as long as it can somehow be applied only to specific projects and PPP profiles.