
K, here's a screenshot of the locks: http://www.geni.com/photo/view/6000000011601866094?photo_id=6000000...
Note that the Cause of Death and Place of Burial fields are grayed out, and the locks are over on the right...
John Tripp, of Portsmouth, Rhode Island
I just pulled it up and the profile picture shows what I SEE if I go into the edit screen....the relationships block at top is missing and the cause of death and place of burial are LOCKED (see right side of screen)...
I have encountered this before....recently
Private User
We are only allowing pros to edit fields that can be easily tracked and reverted. Unfortunately the place of burial and cause of death fields are not yet easy to revert so we lock them for everyone but curators.
I will open a ticket to reopen those fields for collaborators and editors so that they are only locked for people who previously would not have permission to edit that profile.
Sorry, I just confirmed that it is unlocked for collaborators so disregard when I said I will open a ticket.
As we get more and more fields easy to track and revert, they will be made available to pros. You can still request to collaborate on a given profile to be able to edit relationships, place of burial, etc...
Randy Stebbing , Angus Wood-Salomon , Erica Howton , given yesterday’s discussion (above), do you still feel, as you did last week (see last week’s discussion on 6/23 above), that converting profiles to MPs and locking them is a viable solution for those of us who are concerned that PROs can now edit any public profile?
I get the impression that yesterday's discussion was only about locking individual data fields and not about locking the entire profile but I think your question, if I understand it correctly, is more about locking down an entire profile to prevent changes.
There's two issues: MP and locking. Since MP has to happen before a profile can be locked let me cover my view on MP's first:
General Case for making a profile a MP:
In my opinion profiles should be made MP when they are reasonably "done" that is birth, marriage and death dates and locations added, about me section completed and there be at least some basic source citations for where the info was obtained. Additionally all spouses and children added, siblings added and parents identified and merge issues resolved. (Note that in some cases all merge issues can't be resolved because of lack of collaboration, lack of enough identifying information or if the profile is private). What I'm talking about is that reasonable efforts have been made to complete all of the above that is currently possible.
If the profile has existing merge issues with private profiles attempts should be made to contact managers to get the process started to resolve the duplicates. In this process it is absolutely essential that increased collaboration including in some cases the request for making private profiles "public" happens so that the tree immediately around the proposed MP can be cleaned up and stable.
Since there is a perception that MP's have had a knowledgeable person inspect a profile for basic completeness and accuracy I feel that it would be a mistake to make a profile an MP on a very casual basis.
For example there is a profile that I ran into for a Mormon pioneer today that I would very much like to make a MP but with 90 children listed on geni.com, with massive duplication of private profiles, I'm going to first make a concerted effort with the family over the next couple of months to get the facts on the family straight before I start going in and making MP's and locking files.
Now to your question about locking a profile: I wouldn't hesitate to lock a profile given any of the following conditions were evident:
1) Vandalism on it by a geni user, who without regard to historical accuracy, is changing data.
2) If the profile in question is constantly being confused with other profiles with the same name but where they are not matches. In these cases MP status and locking the profile from edits is a way for merges or data changes to be approved on an individual basis by a user contacting the manager or curator.
3) It was felt that a temporary lock on a profile was helpful until a dispute could be resolved based on the best historical data then available. If you feel that any of the above three conditions are evident I'd be more than happy to assist you as would any other curator also.
I support this feature 100% - after 2 1/2 months - asking for Permissions to Add, Fix, etc. information - copied from my public web site of 50,000+ names.
Question: Is it due to "Track and Revert" - that More Fields are NOT editable - something that will be corrected in the Future ??
The 3 Fields I Need Editable - and 2 of them on Basic entry screen:
1) Marriage information (sometimes Only known Location)
2) Residence - Needed on Basic entry - (sometimes Only known Location)
3) "Also Known As" (aka) Field - Needed on Basic entry
Many people use the Given & Middle Name fields - instead of the aka. Field - because it is NOT on the Basic entry. Later, others Remove or Change some of the Given, etc. Names - instead of Adding them in the aka. Field (not being aware of the aka. field)
ps. Is the Cause of Death field - really Needed on Basic entry - instead of: aka. and Residence fields? Does the utilization % support Cause of Death field being on Basic entry?
Thanks
====
2) If the profile in question is constantly being confused with other profiles with the same name but where they are not matches ...
====
The Master Profile program, which started in September 2010, has been iterative.
There are profiles I have made MP's for exactly reason 2 above. If two profiles have similar names, dates of birth, places, they were easily confused.
As a result of the "MP for merging" program we have substantially reduced the confusion and duplication in the geni database. We are moving into what I consider "Phase 2" -- better authored master profiles in the historic space.
Peter Rohel
===
Many people use the Given & Middle Name fields - instead of the aka. Field - because it is NOT on the Basic entry. Later, others Remove or Change some of the Given, etc. Names - instead of Adding them in the aka. Field (not being aware of the aka. field)
===
Enhancements are in the works for this I believe. And very much agree with how it is needed on the "basics" tab.