. . . . . . . . . . {Click on this to enlarge} . . . . . . . . .
There is a lot to talk about, to say the least! Let's begin.
What are your secrets to correct/effective INDEXing?
Do you have suggestions for IX software enhancements?
Do you ever want to send a comment with a batch?
As an ARBITRATOR, what would you tell INDEXERS?
Where are online documents for a Stake Indexing pgm?
Do you want to see some final results of your work?
Do you want to get together at General Conference time?
These are just some of the areas we can discuss/answer.
Watch for a formal FORUM on FamilySearchIndexing.org
We are looking forward to your ideas and participation!
Charlie/Lynnette Shipp, Stake Family History Directors.
Please add your comments: questions, answers, discussion;
also send a note to us at: Charles.Edwin.Shipp@gmail.com
Is it a 'son' or a 'sailor'; a 'mom' or a 'maid'??
ReplyDeleteThere is a significant problem if two Indexers both let it slip by. The Arbitrator will never know, and some ancestor's Mother becomes the 'Maid', and some ancestors' sons become sailors. Wowee!
Here is pseudo-code to fix this lurking problem, so easy.
Actually there are at least two ways for a programmer to fix it.
This is just one approach, sometimes the obvious is the best way.
IF you are in the 'relationship' field; and
. . Indexer types 's' as the first character;
. . . . then fill in the rest as 'son;
Further;
. . If the Indexer types the second character as 'a';
. . . . then change and fill in as 'sailor';
Further;
. . If the Indexer continues typing, allow that to come in.
Similarly, 'Mother' should be given preference over 'maid'!
Another less obvious programming approach could
be to work with the look up table order, but why do that?
hth, sincerely, Charles Edwin Shipp (descendant of many)
Lynnette notes that we never see 'sailor' as an entry as we are indexing. Maybe once in a year. But we see 'sailor' as an error when we Arbitrate. It takes a bit of time when this happens and there is the chance it will slip by. So the 'son' becomes a 'sailor'.
ReplyDelete... What Lynnette suggests (as a programming strategy) is to give priority to the most frequent family relationships we see: Head, Wife, Son, and Daughter.
... Norman suggests a list based on current frequency counts. This could be done by having two tables: (1) one for lookup that is alphabetical; and (2) a separate second table for actually filling in live indexing.
TO SOLVE "THE 'SON' IS NOT A 'SAILOR' PROBLEM":
ReplyDeleteRemember the scripture about plucking out the offending member and remove words from the lookup table that start with the same letter and preceed the following:
... Head
... Wife
... Son
... Daughter.
Charlie/Lynnette Shipp
To purify the INDEXING, here is what you do:
ReplyDeleteRemove the following entries from the lookup table for ‘relationship’ to avoid the common errors currently being made by indexers because of the software:
For Head, remove the following entries
Half Brother, Half Brother-in-law, Half Sister, Half Sister-in-law;
For Wife, remove the following entries
Waiter, Waitress, Ward, and Warden;
For Son, remove the following entries
Sailor, Sergeant, Servants Child, Sister, and Sister-in-law;
(Sorry about removing 'sister' but that's rare.)
And finally, there are no ‘D’ entries before ‘Daughter’, FYI.
It was 'nice', in a way, to have the other entries to see all of the possibilities, but we can now see that they are a hinderance when it comes to the accuracy in the work. The fluff needs to be removed. Save us time and provide greater accuracy for researchers by streamlining the lookup table in these few instances.
It is best to require indexers to type the rare ones in.
Here is another simple solution
ReplyDelete. . . There are so few entries preceding
Head, Wife, and Son (in H, W, and S-areas)
that you can simply edit and move them
before their prior four to six entries !!!
Daughter is already in the front of the D-entries.
Who needs to go to the lookup anyway?
Do not underestimate time saved, accuracy gained!
Consider that SOLVED and move to a new topic: REUNION!
ReplyDeleteThere are several reasons to have an Indexing User Group and this website is just a tool and one aspect of a user group. Another will be the FORUM that will be coming to the formal LDS FamilySearchIndexing website.
But another aspect of user groups and missionaries is REUNION !
CONSIDER THIS :: . . . This is an eMail I just sent:
Brethren, You could show this note to spouses.
Can we start small as a world Indexing users group
(consisting of those doing work, major work, admin,
and past and current INDEXING missionaries) and just
meet for lunch at noon before General Conferences?
We already did this once when the three Shipp sons
and their Mom met Bro/Sister Davis after training.
We had been to the "Early American Writing",
and "Earlier English Writing" (skipping earlier Gothic)
and then went to the Nauvoo Cafe on the first floor
of the Joseph Smith Memorial Building. Was great!
We could do that again with all we can find to join
us, which might be a dozen or two. So that would
be noon April 3rd Friday, Nauvoo Cafe, 1stFl JSMB.
Be there, or be square, Truly, Bro Charlie Shipp
PS: Greetings from Sister Lynnette Shipp, "Hi!"
P2S: Norman, please forward to Bro/Sister Davis.
P3S: Brother Mortensen, please tell Bro Starkey
and others you know: Katie Gale, Bro. Cheney.
P4S: See http://FamiliesIndexingFamilies.blogspot.com
P5S: Please RSVP and tell others to do so also.
As it turned out, I don't think anyone attended. Did you?
ReplyDeleteLet's try REUNION again: Friday noon October 2nd, Nauvoo Cafe.
What a wonderful Blog. Fun stories and tips. I have linked your blog with ours: http://mtpleasantpioneer.blogspot.com/
ReplyDeleteI have been an indexer for over 12 years.
There are several reasons to have an Indexing User Group and this web-site is a device and aspect of a user group. Another will be the FORUM that will be coming to the formal LDS FamilySearchIndexing web-site.
ReplyDeletegroup meeting online