US New York Eastern District Naturalization Records [Part H] - Major issue- NEEDS ATTENTION!!
I have been doing some reviewing for the above project.
For the third time today,( and I have one of these in my batch and will try to keep it (at least til July 6th, per batch info ) so the powers to be can see what i'm describing - i posted the URL at bottom of post as well), i have come across this issue :
The first of the 2 records have 7 consectutive records indexed and the 2nd record has none. And these 7 records appear to be in consecutive order (even the next record that would be the 2nd record).
Just so you can understand, i only have 2 Declaration of Intention records, namely 155118 and 155119.
For 155118, i have 7 entries for it, namely from 155118 thru 115124, with even the correct 155119 in there.
For 155119, there is NO info entered for it. Which just seems odd, since i doubt someone would have entered the other records and not 155119.
So i beginning to believe there is some issues with the system that is making these "records" getting lost.
The batch record i have is MQJW-545
I see in other posts one can use the URL so hopefully i am doing this correctly :
Answers
-
This looks like a malicious indexer. It's unfortunate, but it happens. I'm tagging @Ashlee C. for the batch so she can move it along.
0 -
Let me look into this and I'll get back to you.
1 -
ashlee, just to remention this - this batch is THIRD one i encountered JUST TODAY that was like this.
Thus why i wanted to bring it to people's attention since it definitely seems odd and all.
Thanks
Thomas
0 -
I am wondering if they indexed the two images for the first 2 entries and then used the next 5 reference images for the next 5 entries. I know it's incorrect so they must not have read the PI's.
Lisa
0 -
no - since you only get 2 images at a time with this set of images. And like I said, I've seen this 3 times, and I would think, that something on the system side is somehow putting this info with this batch. And if I had the next 5 images, i would suspect that info would be correct so i think there is something more to it.
And I have a knack (since i am a beta tester in true life) for finding really hard to find bugs that maybe that is the case here.
Sadly i won't be able to key much more with this batch in place since i keep selecting it even when i know which one i should select. So i do hope it is fixed soon so i can keep up on doing reviewing this set of images.
0 -
found another - (Batch id MQJW-BW5)
Also i would like to note the following information should that help on catching these batches with extra information - like the other 3, when doing the image review on this particular batch, the first one was a yes and the 2nd was of "no extractable data" (when it should been yes). That appears to be the theme on all 4 of the batches with extra records, that the 2nd image is reported as no extractable data when there is data to extract.
And in this particular batch, the first image for Petition for Naturalization 319073 has 3 records. The first record for 319073, the 2nd record of the daughter of the first record (which i deleted) and a 3rd entry for Petition 319075.
Although this one batch does NOT have 7 records attached unlike the other 3, it still has a record that shouldn't been even associated with this batch.
On another note, is there a way to "restore" a batch to undo a deletion and/or undo a correction to a line entry (i.e get the batch back to the original condition for review)?? I don't see a way of doing that, barring releasing the batch and even that probably doesn't undo it, i would gather. I am gathering there is no such way. If not, is that a possible item to be added in a future update ?
0 -
Once batches are submitted, they cannot be returned. This has been this way at least since I started indexing in 2014.
0 -
It's most likely that they used the reference images. I've seen that before with malicious batches.
0 -
Well today, i found a 3rd one - batch MQJ4-Q3F
Like the others, image one was a yes and the 2nd image was listed as "no extratable data" when there was.
This one has images for Petitions 146228 thru 146234 in the first set of records.
Again will hang on to it for 1 week.
0 -
This issue was escalated. Thank you for your patience while we worked on it. You can delete entries 2-7 on image 1 and index image 2, then submit the batch.
1 -
i did that on the first batch since i am concerned that the "extra" records that I delete might in some way delete them from their actual records. As I did message your directly to see if those records in question did lose anything, since I do believe those extra records weren't just created by accident (i.e. not from the information on the 2 images I have) but probably are somehow the actual records for those images in question.
0 -
When batches are shared, others cannot see the reference images - only indexers and reviewers can see reference images! But, I know how to find the film, which I did and can see the reference images. On the "third one"- MQJ4-Q3F, the indexer used the next 5 reference images to create the extra records. You can delete those extra entries (3-7) since they will be indexed by the people who receive the records in their batches. You will have to reindex Entry 2, on Image 2, Entry 1 where it belongs!
Often it is a new indexer that doesn't know they only need to deal with the two images in their batch. I think that is the case here. They created an entry for Image 2 as the second entry on Image 1. This happens alot when there are preset records like this project which has 2 preset entries.
The indexer also doesn't know to use Or between the variations or the given and surname. For instance on Entry 4, instead of Jack or Monase as the Given Name, they indexed Jack Monase and then for the surname they indexed Aarons Sfartz, instead of Arrons or Sfartz. It must be done this way so on the published record it will appear as Jack Aarons and Monase Sfartz. They missed the birth year. I didn't check the rest, but, I bet there are more errors.
Thus, I don't think it is malicious indexing. Just someone who doesn't know to click on all the project instructions and also to check the field helps for further instructions! For example, one wouldn't index extra levels of locality on the birthplaces based on the instructions. So, even though we know New York is in the United States, we don't index United States, unless the birthplace was recorded as N.Y., N.Y., USA.1