Compton-2184 Draft Proposal re Profile Management Reform (2019)

Date: 2019 [unknown]
Location: [unknown]

2021 Update to these thoughts: Since I drafted this proposal, WikiTree Admin has implemented an effective process for actively identifying inactive profile managers and orphaning their profiles, which has greatly improved access to these profiles upon which collaboration was previously inhibited. (Compton-2184 17:40, 28 October 2021 (UTC))

2019 Proposal Draft

Proposal: Require periodic renewals for PM control over profiles. Reminders about renewal should be sent by email in addition to any on-platform nudges. Profiles whose project managers do not renew should be orphaned, with the following exceptions:

Users to be exempted from the requirement to renew:

Consistently Active Users (subject to definition)

Users with Special Permission

Project Profiles

Profiles to be exempted from the requirement to renew:

WikiTree members, volunteers, and their immediate family (subject to definition)

Profiles b. after 1867 with a privacy lock

Living people

Profiles that may not be renewed:

Pre-1500 and pre-1700 profiles for which PM is not badged

Profiles with more than X managers

---

Who are consistently active users?

• Leaders, staff, mentors, G2G mods, greeters, rangers (projects with regularly scheduled duties to WT)
• X contributions each week/month for Y weeks/months
• Data doctors with X minimum tracked edits in Y time

Who are users with special permission?

• Users should be able to contact WikiTree admin to explain why they should not need to renew their PM status periodically. Users with health concerns or unreliable internet access would be good candidates. It is important that WikiTree be accessible to users with a wide range of knowledge sets and internet skills, and to accommodate contributers outside the normal use cases. I trust the WikiTree owners and leaders to be able to identify the criteria for this exception that would make this proposal feasible both in terms of technical capabilities and of staff availability.

Which profiles are a PM's immediate family:

• PM's descendants, parents, grandparents, great-grandparents
• PM's siblings, aunts, uncles, nieces and nephews, and first cousins
• same rules for adoptees

This proposal is offered under the assumption that the identification of profiles whose PMs need to be renewed can be done by a bot rather than by human review, and that the renewal nudges can be sent by an emailer bot. This proposal assumes that Admin and community managers will see an increase in inquiries from lapsed users but that those inquiries will drop off over time as profiles managed by minimally active PMs are orphaned.

Why? WikiTree models collaboration as directly peer-to-peer (social) and addresses collaborations that don't work as interpersonal conflicts to be mediated. This model is appropriate for puzzles about specific research questions (ex. Where was our ancestor born?). However, collaboration on a shared data set is not always directly one-to-one. In a shared dataset, access permissions are the primary mechanism for regulating broad collaboration among many users.

Access permissions allow users to contribute data to be verified and validated by other users, while protecting validated data from being tampered with by malicious or naive users. Access permissions restrict information and edit rights to certain users to achieve those goals. All of us gained access permissions to edit the WikiTree shared tree when we agreed to the honor code, and virtually all of us lack access permissions to certain functions that are restricted to trusted users.

Currently WikiTree uses access permissions in a disorganized way, which leaves new users feeling confused about how to contribute data. At one end, for ancestors born between 1700-1866, a brand new WT volunteer can edit any field in any way they like, up to and including assuming Profile Management. At the other end, to edit a project-protected pre-1500 profile, a WikiTree volunteer must develop a substantial body of contributions sufficient to persuade at least one human volunteer that they understand genealogy and WikiTree, and some portion of those contributions must be in collaboration with an already-established Project.

In addition, to participate in many Projects, a volunteer usually must establish an offsite groups.google.com presence, and cannot learn about this technical requirement without browsing Project pages.

As I understand the history of WikiTree, at the beginning users were welcome to upload thousands of gedcom profiles to populate the shared tree. The process of validating and reconciling (merging) those initial data contributions has been laborious and often frustrating to those doing the most work, and our current access permissions inconsistencies have arisen in that context.

Profile Management is an area of particular confusion. For example, one area the Profile Manager does not control, on profiles without a privacy or PPP lock, is what data is contributed to the profile. A Profile Manager is expected to engage on a collaborative peer-to-peer basis with contributors to the Profile to resolve research questions. If a PM does not appreciate contributed edits, their recourse is restricted to either 1) reverting unwanted edits or 2) engaging in Problems with Members process.

It appears to be WikiTree's position that a PM's lack of control over edits promotes collaboration on open profiles. That is, we are encouraged to "Be Bold" and also to "Be Polite" and somewhere in between those two directives is where our peer-to-peer interaction with a profile's PM should lie.

However, peer-to-peer collaboration on specific biographical details is not the only kind of collaboration WikiTree promotes. Because we are all working on one shared tree, we become "visible" to family historians on related branches we might have had difficulty locating in the real world. That visibility is an important part of the collaboration WikiTree fosters. And it can occur without direct peer-to-peer contact about a specific biography. A cousin I trust for having solid data might make 100 edits before they add something I want to know more about to a profile I didn't create. WikiTree promotes collaboration by letting me see whether that edit is sourced, and if so, maybe that source will be useful for a profile I manage. WikiTree even encourages me to thank my cousin remotely with one click which is an amazing function.

The edit feed is a powerful tool for promoting collaboration, and thousands of them are locked down under the control of a mostly absent Profile Manager. Because Profile Managers control access to the Trusted List on a profile. And access to the Trusted List is the same as access to the edit feed. Users who complain about this situation are told that they can edit the profiles anyway, because they're Open. Which is true, but it is a different set of access permissions than the ones provided by being on the Trusted List.

The edit feed is also essential for catching misinformation or clutter being added to profiles, so volunteers can be educated about how WikiTree works by a person with familiarity with the ancestors whose profiles they want to edit.

Another important power of the Profile Manager(s) of a profile is to receive direct message inquiries about profiles by users who are not yet members of WikiTree or who do not want to post publicly. The lack of an internal direct messaging system in WikiTree is its own problem that could be addressed in various ways (adding a Talk tab to profiles, adding tiered access to G2G threads, or adding a DM system) but as long as that function is bundled into the Profile Manager's access permissions, we need to recognize that minimally active PMs probably inhibit collaboration in ways that users new to WikiTree have no way of understanding.

It is well known that WikiTree was set up based on the belief that users would contribute quality data for ancestors whose profiles they would be invested in maintaining in good order. However, the real situation is that millions of profiles are neglected for years after being created by users who did not understand WikiTree's expectations or who have chosen not to participate according to them.

Many of those neglected profiles are still "managed" by WikiTree users (the original creator or a later adopter) who do not appear to be watching their Family Activity Feed. These users, for example, are slow to approve merges and Trusted List requests and sometimes have to be pestered with follow-up profile messages and direct messages.

The hassle of engaging with users who are not using their greater access permissions is a deterrent to collaboration. It is inconsistent with WikiTree's mission to allow these users to monopolize access to activity feeds on profiles. And it's frankly obnoxious that users who want improvements to this issue are told essentially to get over it, it's not a problem, or even that they should send more WikiTree spam to the PM to make absolutely sure the PM doesn't want to "collaborate".

From a user interface point of view one solution would be to remove the monopoly control over a profile's edit feed from the Profile Manager's suite of access permissions. WikiTree says the programming will not allow this change to the PM's suite. Will the programming accommodate some kind of add-on function? The best case scenario would be for all edit feeds to deliver to a single page like "Family Activity Feed" but a workaround could be for there to be a secondary Feed page pulling opt-in RSS-like data outside the profile manager's control.