US, Virginia—Marriage Records, 1853–1935[M3WL-L64]
US, Virginia—Marriage Records, 1853–1935[M3WL-L64] the project is flawed. The fields to be filled in cite "Marriage License", but the project is for marriages. Marriage License date and locations have nothing to do with when and where a marriage is performed. As the project is for filling out Marriage information, the first two fields for filling marriage information, are mislabeled. They should say Marriage not License.
Best Answers
-
Have you submitted the batch? I am getting an error message with that batch code. We do index Marriage Licenses as Marriage Records. The Marriage License City or County is indexed from the Header information (per the examples). The Marriage City or County is taken from the 3rd column. We've been indexing these same types of Virginia Marriage Registers for a very long time. I started indexing them in April 2020.
0 -
Hi Starcaster.
I may be the only one getting the error message that access is restricted. It usually happens when the batch has been submitted. But, I have worked on a lot of Virginia Marriage Registers and feel comfortable discussing the project without seeing your batch.
These instructions and entry forms are designed by the owners of the records in conjunction with the FamilySearch team. As abovementioned, I began working on these in April 2020 as a special project with a small group of "invited" indexers. They were so particular that even though I have reviewed hundreds of thousands of records on FS, I was not allowed to participate in this review process. The indexing did not follow the rules that I was used to, but, I followed the somewhat odd instructions. Even though we disagree with the way they are indexed, or the information that is requested, we have to follow the project instructions and examples.
The field help for the cities and counties also drives me a little crazy: If the marriage place was not clearly indicated as city or county, please index the place in the county field. Do not index places of residence, churches, stores, or other localities in this field. As a child, we enjoyed our summer vacations in Fairfax on my great-grandfather's farm off Lee Highway. My first full-time job was in Richmond, where I spent 18 months. So, I am familiar with the independent cities of the state along with all the other towns and cities. I feel your frustration; it is hard to index them in the County field, but, that is what the field help and the examples show us to do.
0
Answers
-
I have not been getting error messages.
The problem is that license info are different gedcom fields than marriage info. When the product is given to the customer and published, it will show license date and location that does not exist in the image.
I see this problem on Ancestry all of the time and if a person is not sharp, they may not realize that the record was indexed improperly. No licensing information should be going into those fields as licensing is not part of the image in this project, at least not from the thousands of records I have reviewed.
Another thing is location. Certain Virginia cities are independent and are not part of counties. If an independent city is indicated and the record indicates city, the county would be blank. Unless you live in Virginia, one would probably not know that. An example would be marriages performed in Alexandria City. That is an independent city, so it is not in a county. If county is not crossed out or the term city is not in the header, then I would put Alexandria as the county and leave the city blank. This might also be incorrect as the register may not have properly indicated the location.
The instructions telling indexers to enter any licensing info based on the project I have been working are wrong. The licensing fields should have been left blank as they are not part of the image. It is a marriage document absent of licensing info.
0 -
I agree with everything you said.
What gets me is that people who should know better, whether the customer or Family Search, make mistakes and more frequently than you might imagine. For example, US—City and Business Directories, 1749–1990 [Part C], the reviews I did, well the directories did not have any location printed on the header. So, one can index and review all day long, and you end up with a worthless product because if you do not have a location for the directory, nothing else matters. You can't tie it to anything.
Yes, we have to follow the instructions, even if they do not make sense. I have been doing genealogy for 55 years and have over 60,000 indexes and reviews. It is not infrequent to find errors in the way things were set up, and the pat answer I got from Family Search saying that is what the customer wanted, well I just have to wonder about the process and what goes on behind the scenes.
If I were doing it, every appropriate gedcom field would be filled in. Otherwise important information is lost, perhaps never to be found. This is because many of these records wind up as text only, so there is no way to see everything that is available.
There is a lot going on. The customer gets the images from NARA with the proviso that they be indexed and returned to NARA indexed within x number of years. The customer (mainly the free sites the church is partnered with) fulfills the obligation by having the church (Intellectual Property Reserve) index the records for payment in kind for site access. There is also some work they get paid for which pays the 2 salaried employees of Family Search and the running of Family Search, i.e., servers and so forth. I am not indicating there is anything wrong with that, just explaining the system.
The only reason that I can think of why more or all gedcom fields are not indexed is probably a function of time and volume on both parties part. There are project goals and volume quotas, so indexing every field probably won't be done, unless it is something with a small number of fields. But, why mistakes are made in instructions and fields is a puzzler. Yes, the rules in some projects are certainly not what would expect.
0