MQLR-9M6 Ghana-2010 Census [Part D] The family information starts on Page 3

HughesAlysonAdams

I've been doing these records for a while, but suddenly they are coming in with the first page of the family on about Image 3. I am of the idea that would be the first page, since the data on page 1 and 2 does not belong to this family and would be marked NED since the information on 1 and 2 family would be indexed in the previous batch. However, most of the batches I encounter have been indexed on page 1, even though the first page isn't there, and then indexing page 3 as another "first page". I hate to mark page 1 as NED and lose the information if I am incorrect even though that page, in my mind would have been indexed previously with the first page that matches it. Please set me straight on what I should do.

Thanks very much. 🌺

Julia Szent-Györgyi

Oof, confusing project instructions.

The pre-indexing popup starts:

• Census records may continue across multiple images. Index the information on the first image in the batch, using information from all images in the batch. When all available fields have been indexed on the first image, other images should be marked in Step 1: Images as No, No Extractable Data.
• Verify all images in the batch are from the same household by checking the Quest ID. number in the top right-hand corner of each image. If some images in the batch contain a different Quest ID. number, create a separate record starting with the new number.

So indexers are just following instructions when they index those "tail-end" pages. I suppose they figure better twice than not at all, and I can't disagree with that.

The second bullet point is repeated in the What To Index section of the project instructions, so we can't say that the project has completely ignored the possibility of indexing batches not matching up to households, but these instructions are difficult to reconcile with the usual indexing precept that we fully index every entry that begins in our batch.