Why don't you remove the departure date from the Albany Australia shipping record
These records are totally a record of arrival dates into Albany and where they came from. As a reviewer I have just returned 5 batches for re-indexing because indexers are putting the arrival date in as departure dates, which, in fact, are not known. So I suggest we remove departure dates from these batches. We are wasting a lot of peoples time!!!!!
Answers
-
Attention: @Melissa S Himes & @John Empoliti As this relates to "Indexing". Perhaps, you may wish to 'Comment'
0 -
Unfortunately, this is one of those Australian projects that must be limited to indexers in that country. So, I'm going to guess that there are at least a few other fields than than the given and surname and arrival and departure dates and where they came from. But, even if there are only 5 fields on the entry form, reviewers should not return these for reindexing just because the arrival or departure date is in the wrong field.
Returning a batch for reindexing should be rare event. The Help Center article tells us:
- The indexer only indexed a couple of records out of many on the image or marked many blank that should not be.
- The indexer marked an image as having no extractable data, but the image has many records to index.
- None of the information that the indexer entered matches the information on the image.
As reviewers, we usually need to correct the information and submit the batch. There are tricks to make this really simple in a case like this, like using the copy text forward key to change all the dates at once. You can use CTRL + B and make the first record's departure date field blank and then use the copy text forward key to render all the records departure field blank. Then put the correct date in the arrival field and do the same. It literally takes seconds to perform this operation. (I'm assuming that the ship records all have the exact same arrival date.)
Now, to the question, why is there even a departure date field on the entry form anyway? The project managers have most likely gone through the records and at some point in the thousands of records found forms where there will be departure dates. They might not even be in the part of the project now being indexed, but could show up In later parts (Part A, B, C, etc.) so for consistency they have put both date fields on the entry forms.
My question is are folks not reading the Project Instructions, Field Helps, or examples in order to determine which entry field they should use or is there an inconsistency in those instructions? It would be odd to find that many batches that didn't have the proper date field indexed.
I will tag two people I know who could be indexing these forms and be able to offer better insight:
@Ontymay and @PatrickCox6
Here's a link to the Help Center Article on Returning Batches for Reindexing.
Hope that helps a little.
Happy Indexing!
3 -
Melissa has mentioned all that needs to be and can be without seeing a batch.
1 -
Hi @Dekmar, I have had similar confusion with these Inward Passenger Lists. The Project Instructions state to use the date (if only one date is on the record) as the departure date. This does seem odd to me, as they are Inward Passenger Lists. However, I am told that the Project Instructions are to be followed. Comment from an Australian moderator may help to clear up the confusion.
1 -
Thanks @PatrickCox6 for responding. That certainly explains why there are so many batches with the departure date indexed. The indexers and reviewers are correct to use that field when only one date is present!
0 -
Yes, that meets the project instructions, but it still gives A researcher incorrect information. I don’t want my name associated with that.
I have just spent about 3 times longer on a batch switching the entry from departure to arrival and feel good about it. At least the result I produce is correct.
0 -
The problem is that when everyone doesn't follow the project instructions, it creates chaos. If the instructions say that when only one date is on the record to index it as a departure date, then that is what should be done. There are reasons that the projects are set up as they are. Perhaps putting the only date in that departure column is done so that when a report is run the project managers can specifically look at those images. We just don't know. There is a lot of work that goes into these records after indexing and prior to publication. I hope that you will trust the system and follow the project instructions or move on to a project that meets your requirements. But, I do understand. I have walked away from projects that I loved just because I didn't agree with the instructions. (Also, keep re-reading the instructions because sometimes they do get changed because of posts in the community.)
2 -
Hello friends,
This Albany Arrivals project has been languishing for a while and I gave up on it.
The reading and following of the Project Instructions is the fundamental problem and not restricted to this project. In this case the instructions are clear.
As a reviewer, I feel bad reindexing someone's work, but only when the instructions are unclear; when the instructions are clear then I just feel cranky that they have not been followed. I have gotten hard over time.
@Dekmar the images will be available so that anyone who finds an entry on the index can then inspect the document and decide for themselves if they think a date is an arrival or departure (in any case departure and arrival dates will not be too far apart).
Also, when a reviewer changes more than a certain percentage of the entries the record goes back to be re-reviewed. So if Reviewer-1 does not following the instructions, and switches the entry from departure to arrival, odds are that it will be re-reviewed and Reviewer2 (who is following the instructions) will change them back again, triggering another reviewing (or whatever happens next). It becomes a never ending cycle of changes and causes the project to stall - that is thesort of chaos that @Melissa S Himes referred to.
@Dekmar you might have more fun with the Victorian probate project which is generally in pretty good shape (some folk still can't follow the instructions but that is always the case) and needs reviewing.
cheers
1 -
Hi @Ontymay
It's not a never-ending cycle - after 3 Reviewers who don't agree within 20%, it goes to a special FS team to make a final decision.
2 -
oh, good to know - still makes the project stall though
thanks for the accurate info
0 -
Yes, needing more than one Review is never a good thing.
0
