Oh, dear, Terri! Believe me, we really do want and need your help, if you are willing... Surprisingly for me, it seems that not many members are interested in writing biographies.
I think some of the experiences you are talking about probably are things that happened several years ago -- before I became Project Leader, which was in late 2017. I cannot speak for what was done back then, but only for my own actions and our current policies and practices.
Different project leaders seem to have different philosophies on projects as profile managers. When the NNS project is a manager on a profile, I want the project to be an adjunct to the individual human managers, not a replacement for them. I am dismayed when a member removes themselves as profile manager after the project account is added, and declares that the project is henceforth responsible for their ancestor's genealogy (that seems like turning your children over to the state to be placed in foster care). The project leadership has nowhere near the bandwidth, much less the interest, to do the genealogy for all of the thousands of profiles for which it is a manager. The project is on those profiles for purposes like trying to prevent duplicates and deal with them when they turn up, helping to ensure consistency of policy, ensuring that important profiles don't become orphaned when a profile manager passes away or leaves WikiTree for some other reason, and helping with genealogy when needed. I don't generally remove members from the profile manager slot (at least not deliberately) unless there are several other managers and the member is inactive (for example, yesterday I removed profile manager status, on one profile, for a member who had not been seen in WikiTree since 2013, but I did leave him on the trusted list). However, when a profile is merged into a project-protected profile, the profile manager of the merged-away profile does lose their PM status automagically. Many of the profile managers who are converted to trusted-list only status because of a merge are members who created a brand-new duplicate profile a few days before the merge; that kind of irresponsible action shouldn't be 'rewarded' with profile manager status on a high-visibility profile. However, it can be difficult (and confusing) to keep track of those changes (particularly when the merge is completed by a passing arborist), so it is likely that some very responsible project managers lose that status when a profile is merged. Fortunately, any NNS project member can become a member of the Google Group that receives notifications for all profiles that have the project as a manager (so you can see the notifications without getting them in your personal email box), and a member who feels they have been wrongly removed as profile manager can ask me (or another member who is project manager) to restore their status.
I am sorry that you don't like the way the project deals with LNABs. It took me a good while to appreciate the reasons for the naming convention (it took me even longer to grasp the logic of the arcane merge approval process that the project formerly used), but I have drunk the proverbial Kool-Aid and I am now a confirmed believer. As I believe you know, in the earlier days of WikiTree New Netherland was plagued with numerous duplicate profiles, in part because one person could be known by so many different name spellings and often even by two or more completely different last names. Determination of "correct" names has been a chronic challenge. Our current naming convention for LNABs is our special implementation of the WikiTree-wide naming convention at Help:Name Fields that says: We aim to use the names that people themselves would have known and that would have been recognized in their own time and place. Rather than engage in lengthy philosophical discussion about questions like which of the five names that appear on the baptismal records for a group of siblings is the "correct" name for that family, we treat each child separately based on contemporary records for that specific child, and we have a set of somewhat arbitrary rules. For children born in New Netherland we use the last name of the father on the particular child's baptism record. If the father was using a patronymic name at the child's baptism in New Netherland, we look for later records that show a last name that the child was later recorded with (almost always as an adult), rather than assuming the child had a patronymic based on the father's first name (and guessing at the preferred spelling for that assumed patronymic). For people born in the Netherlands, we often need to consult with Dutch Roots regarding the appropriate name for the child. And the single most important guidance regarding names is to make sure all of the known names and spellings for the person (including names known only to later generations) appear in the profile -- including name fields like Other Last Names as well as the biography, so the person has a decent chance of turning up in searches, regardless of what name variant is being searched. (Now that WikiTree name search looks at Other Last Names and Other Nicknames, and ignores the spaces in names like Van_Alen, there is a much better chance that New Netherland profiles won't be overlooked.)
Implementation of this policy does mean that when two or more profiles are merged, we no longer merge to the profile with the better-looking LNAB. Instead, we try to determine what the LNAB should be, and if none of the existing profiles uses that name, we rename one of them to that name to become the merge destination for the others. Yes, more than a few profiles get their LNABs changed, but with a clearly articulated name policy, this should not have to happen more than once for any one person's profile. When an LNAB is changed, nothing else about the content of the profile is altered. The history on the renamed profile does appear to be wiped clean, but the whole prior history is still readily available. To find it easily, go to the Changes page for the renamed profile (for example, this Changes page for Rosa-460) and look for the edit that changed the LNAB. In that entry (on the Rosa-460 changes page it is Merged Roosa-17 into Rosa-460: Father's name at her baptism), click on the hyperlink for the profile that was merged away to see all of the history prior to the LNAB change.
All too often, we still see members creating duplicate profiles that need to be dealt with, but project leadership does not "create duplicate profiles with different spellings to use to merge away the accurate profile being managed."
