Different County
Hello,
I am reviewing batches from UK, England, Herefordshire—Bishop's Transcripts, 1583–1754 [Part C][MS2Y-P2M]. The county in this instance is Salop (Shropshire). Should these records be indexed or marked as NED? I can't find any mention in the Project Instructions or Purple Circle guides about this. It does state that records outside the specified DATE range should be indexed, but no mention of the locality.
Many thanks
Hilary.
Best Answer
-
"Index all baptism, christening, birth, marriage, marriage banns/intentions, death, and burial records"
Yes, you should index this.
2
Answers
-
Dear DHilary2, The Project instructions state:
- Records that are outside of the project date range should still be indexed.
- Index all baptism, christening, birth, marriage, marriage banns/intentions, death, and burial records, including those outside of the date range of the project.
So, Yes, this image should be indexed if it contains baptism, christening, birth, marriage, death or burial information.
Thanks for asking. And thanks for indexing/reviewing. And thanks for checking the Project Instructions and Field Helps. You are doing a great service!
1 -
Thank you for your answer. However my question was about COUNTY not DATE. I have seen in other projects instructions about the place - usually to include those outside the prescribed boundaries, but there is nothing that I can see in this one.
The records in this batch refer to a parish in Shropshire, not Herefordshire - although it may well be within the Diocese of Hereford, but that's not the same thing at all.
Many thanks,
Hilary.
0 -
Thank you!
Hilary.
1 -
Just as a follow-up to this question, I have just been trying to help someone with another project (Northumberland Non-Conformist Church Records) and the instructions for that say:
- Index all birth, baptism, christening, marriage, death, and burial records, regardless of the county where the record originates.
Because it didn't say that last bit in the Herefordshire instructions, I felt it wasn't at all clear that that is what I should do. Why mention the exception in some projects and not others? if you have seen that it has been mentioned before, it is not illogical to assume that if it isn't mentioned in your project, it doesn't apply. In fact, why give projects a definite place and date range if neither is to be adhered to?
Hilary.
0 -
The project instructions are different for each project because FamilySearch does not decide how a project is to be indexed. It is the owner of the records who is allowing FamilySearch volunteers to index the project who makes the decisions about how the project is to be indexed.
May I suggest that you read the Project Instructions for each project, and review the General Indexing Guidelines from time to time. Also, use the Field Helps. (I'm sure you are already doing these things). If you still have questions about a batch you are indexing, please post here. Please include the batch number each time. (Format: [XXXX-XXX]). We will do our best to answer each question you may have about each particular batch.
Thanks for indexing and best wishes!
0 -
Hello again,
Thank you for taking the trouble to respond. I absolutely do read all the instructions going for each project I tackle. They don't always help! I understand that it's the owner of the records who decides what and how things are to be indexed. I think you missed my point. That is NOT the issue. It's how those instructions are relayed to indexers. To put in one set of instructions that all certain types of records are to be indexed, giving the exceptions of place and date and a clear statement of what is NOT to be indexed is helpful. To only put in another set of instructions that records outside the DATE range are to be indexed (plus the sort of records that are NOT to be indexed) but to omit to say that records outside the stated PLACE should also be indexed is not helpful and surely is purely how the instructions are written, not what the owner wants to be indexed and how. I'm asking for consistency across similar sorts of records.
Hilary.
0