Corrections Process

Introduction

This page describes the FreeBMD Corrections process.

The corrections referred to here are those submitted by researchers when they find something wrong with an entry and invoke the corrections process by clicking on the appropriate link in the Information page for the entry. Hence what is being dealt with are "ad hoc" corrections not systematic corrections which are handled by the FreeBMD second keying process.

Transcribers can nominate whether or not they are willing to handle corrections to entries they have transcribed. If they opt not to, then it is up to the syndicate coordinator to determine how to manage the corrections.

When a correction is submitted the FreeBMD corrections process creates a correction item which contains all the details of the requested correction and the unique identifier that the correction process has assigned to it (the correction id). The correction process assigns an Owner to each correction item which may be the original transcriber, the syndicate for whom the transcription was made or another nominated person or syndicate. The owner is requested to make the correction or reject it (if it is not valid). Under some circumstances the correction process may change the owner. Once the correction has been completed (done or rejected) a response is sent to the original requester. There are a number of exceptions that can occur and facilities are provided the handle these by routing the correction item to nominated people or administrators.

Process Flow

In technical speak, the FreeBMD Corrections Process is constructed as a "workflow". That is the correction is passed from one stage of the process to another and at each stage the correction is in a particular "state". A straightforward correction would proceed as follows:

Submitted	A researcher has raised a correction	The system loads corrections that have been submitted into the corrections system with a state of Submitted

Assigned	The system has determined who should handle the correction	The system determines from the transcription and the configuration settings for the syndicate for which the transcription was made whether the syndicate or the transcriber should become the owner (and, of course, whether the transcriber accepts corrections).

Completed	The transcriber has done the correction	The transcriber does the transcription (if it is valid) and marks it as complete. Alternatively the transcriber may mark it as rejected if the correction is not valid.

Finished	The original researcher has been notified that the correction has been done	The system sends an email to the requester notifying them that one or more of their corrections has been done or has been rejected

There are a number of variations on the above process, most of which are explained below. The ones that are not explained occur rarely and are handled by the technical team, for example if a submitted correction cannot be assigned then it is goes into the Unassignable state.

Responsibilities

Normally the primary responsibility for implementing a correction rests with the transcriber who created the entry in question. The Corrections process will notify them that there is an outstanding correction, they will examine the request and determine whether to implement the correction or reject it (for example, if the change cannot be justfied by the available scans).

If the transcriber cannot or will not handle the correction it is passed to the syndicate for whom the original entry was transcribed. In terms of the process the person handling corrections for the syndicate (who may be the coordinator or another nominated person) then acts very much in the same way as the transcriber, implementing the correction or rejecting it, although they can also pass it to another person in the syndicate.

Who is responsible for a correction is recorded in the correction system as the Owner. Normally this is changed by the correction system in response to the attributes of the correction or actions taken on the correction but it can also be changed explicitly. Ownership by a syndicate is indicated by the owner being "synd:syndicatename".

Facilities are also provided for all corrections for a syndicate to be passed to the syndicate, rather than to the transcriber. Each syndicate can nominate a particular person to receive the corrections for a syndicate although this defaults to the coordinator.

Corrections have an owning syndicate (where a transcription has been done by a syndicate) and how a correction is handled by the correction process is determined by the configuration of the syndicate as well as the transcriber. Where a correction is for an entry that has been transcribed more than once a correction will be generated in the correction process for each one and these will proceed entirely independently through the process and each will be handled according to the configuration of the syndicate and transcriber.

In overall charge of the Corrections process is the Corrections Coordinator who has responsibility for setting the parameters that determine how the process works, for example the text of the default email that is sent to the transcriber.

Notifications and Alerts

Notifications and alerts are communicated via email, which, unlikely previously, do not contain the actual correction but instead contain a link to a page on the website that displays the corrections. (The advantage of this is that transcribers cannot use stale data.)

Notifications: These communicate that there are corrections that are waiting to be processed - transcribers can limit how many corrections are notified and can request that corrections are batched
Alerts: These communicate that there are items that need attention, for example that there are corrections that have been outstanding for more than a given period of time - for example syndicate coordinators can be notified of transcribers who have not been processing corrections

See the sections on "Configuration" for how the above can be customised.

Displaying Corrections

Outstanding corrections can be displayed (as a list of references) determined from a number of criteria. For example, all the outstanding corrections for a transcriber, all those for a syndicate, all those after a certain date, etc.

There are two ways in which such a list can be generated. The first is through the use of a selection screen which allows the various criteria (as in the example above) to be specified. The second is from a link in a notification email which will only display those corrections that correspond to the criteria set by the transcriber, for example only sending a notification for five corrections in any one week.

Clicking on an item in the list will take the transcriber to the details of the requested correction which includes the details supplied by the researcher as well as links to the file and the scan (where there is one and it can be determined).

An alternative to having the list displayed is to download the list as a CSV (Comma Separated Variable) file that can be manipulated using a spreadsheet. It is envisaged that this facility will be of more use to syndicate coordinators than transcribers. The file contains one line for each correction with all the details of the corrections.

The fields shown, both for display and CSV file download, and their order can be configured from the selection screen.

Completing Corrections

Once a transcriber has examined a requested correction they will either make the change as requested or reject the correction. The page showing the details of the correction has buttons that allow either of these to be selected, and with the rejection there is provision for the reason for the correction to be given (which will be communicated with the original requester).

It is also possible to indicate that corrections have been completed by uploading a CSV (Comma Separated Variable) file, typically a modified version of a file of corrections that has been downloaded. There is a column that indicates that a correction has been completed or rejected. The response to uploading such a CSV file is the download of a version of the file with the results, in particular this is the way errors are reported. The meaning of the columns in an uploaded CSV file is determined by the titles in the first line and the following columns are used in the upload process:

ID

The identifier of the correction (mandatory)

Outcome

The outcome of the correction which for each correction must be one of:

Complete - The correction has been completed as requested (Reason ignored)
Reject - The correction has been rejected for the reason given in the comment (Reason mandatory)
Reassign:userid - The correction is to be reassigned to userid as the new owner - this is only permitted if the CSV file is uploaded by a syndicate coordinator of the syndicate owning the correction and userid is a member of the syndicate (Reason optional)
Reassign:synd:syndicatename - The correction is to be reassigned to the syndicate syndicatename as the new owner - this is only permitted if the CSV file is uploaded by a syndicate coordinator of the syndicate owning the correction (Reason optional)
blank - No action is taken (Reason ignored)

Date

The date at which the outcome took place - this is optional and if omitted the date of the upload will be used

Reason

For some Outcomes a reason is required, for others it is optional and for others ignored. See the Outcome definition for which applies.

Result

This column is optional. Any contents will be overwritten in the resulting spreadsheet.

The response to uploading a CSV file is a results CSV file with the same columns as the uploaded CSV file (plus a Results column if one does not exist) which gives the new State for each of the corrections in the original upload plus an entry in the Result column if the action could not be completed. Note that the content of any columns other than those specified above is ignored and replaced in the results CSV file with data from the corrections database (so, for examaple, if the uploaded CSV file contained an incorrect Submitted date this would not affect the upload but would be replaced by the correct value in the result).

Reviewing Corrections

The corrections process provides a step for reviewing the corrections that have been done, before the response email is sent to the person requesting the correction. This can be configurated for an entire syndicate or for individual transcribers. After the person doing the correction has completed it (as Done or Rejected) the correction goes into the Review state with the syndicate as the owner. The syndicate can then review the correction and determine whether it should be finalised (and the email sent) or returned to the transcriber. Notifications and alerts for items in the Review state are provided.

It is anticipated that syndicates might want to review how well syndicate members are handling corrections, especially if they are new to transcribing. Once a syndicate has confidence in a member they can allow them to do corrections without review. This, then, provides a means to review how corrections are done, and to determine the need to do a review, without having to review every correction. However, syndicates can, if they wish, review all corrections before they go to transcribers simply by setting the configuration item SendTo to be "Syndicate" (only) and then reassigning the correction to the transcriber once it has been checked (or rejecting it if invalid).

Syndicates

Transcriptions are normally done for a particular syndicate and the system records this syndicate as part of the file information. However, transcribers can belong to more than one syndicate and indeed may change syndicates. Where a syndicate is referred to it is always the syndicate associated with the file not the syndicate to which the transcriber currently belongs.

Multiple or changed syndicate membership can cause significant complications in the comparitively rare situations in which it occurs. For example, if a transcriber has got correction requests for files that were transcribed for different syndicates and these syndicates have different methods of handling corrections, the corrections process may have to send separate notifications for the different files.

Configuration

The corrections process can be configured at three levels

Base: The Base configuration provides the overall setting for the correction process and the defaults for items that can be configured at syndicate or transcriber level - only the Corrections Coordinator or deputy can alter the base configuration
Syndicate: There can be a different configuration for each syndicate and, for each item that can also be configured by the transcriber, it provides a default - the syndicate configuration for a syndicate can only be changed by a coordinator of the syndicate
Transcriber: Transcribers can configure how their interaction with the correction process works and this is controlled via the modification of their Submitter details

There is a hierarchy in the configuration system in the order indicated above and part of the configuation determines how items flow down through the hierarchy. For each item there is a flag which indicates whether it can be amended by syndicates and transcribers and whether it can be seen by syndicates and transcribers. This allows syndicates to choose what items their transcribers can see and change. However, where a transcriber belongs to more than one syndicate the least restrictive setting applies unless both can be accomodated.

It is also worth noting that the setting of the "Accept corrections" flag by transcribers is also used by the Corrections process although (for historical reasons) it is set separately from the rest of the transcriber configuration.

Templates

The emails that are sent as Notifications and Alerts are generated from templates. These templates are configuration items which syndicates can change.

The variables that are used in the templates and the construction method are described elsewhere.

Authentication

All access to the process is authenticated with userid and password. The logon process is extended to enable transcribers to request a logon as a coordinator of one or more syndicates. Obviously such a logon will only succeed if they actually are coordinators.

Resilience and Auditing

Every correction request has a unique identifier. In order to avoid possible issues with incorrectly entered identifiers (and, indeed, to thwart hacking) the identifiers have a check code so only identifiers generated by the corrections process are valid.

Every change is recorded thus providing an audit trail of what changes were made and by whom.

Definitions

Flags

The table below defines the flags that are associated with corrections. There are three categories:

Key: The one letter key is used in the listing of corrections when there is a flag value
Selector: The selector is used in the correction selector page when it is desired to search for corrections dependent on one or more key values
Explanation: The explanation tell you what a particular key value means and is also displayed when viewing correction details

Key	Selector	Explanation	Notes
X	No file	The file no longer exists
N	No syndicate	The correction could not be assigned because there is no syndicate for the file
E	Transcriber does not exist	The transcriber no longer exists
M	Multiple syndicates	The correction could not be assigned because the file is attributed to multiple syndicates	When the transcriber created the file, they were a member of more than one syndicate that were trascribing the quarter. The system cannot therefore detrmine which syndicate the transcription belongs to.
D	Syndicate redirect	Syndicate rules caused the correction to be redirected
R	File replaced	The file referred to in the correction has been replaced (replaced name shown)
A	Not accept corrections	Correction could not be assigned to transcriber because they do not accept corrections
S	No syndicate contact	Correction could not be assigned to syndicate because there is no syndicate contact
U	Transcriber uncontactable	Correction could not be assigned to transcriber because they were uncontactable by email
C	File changed	The file has been changed since the correction was submitted	The correction may now, therefore, already have been done.

State

Every correction must be in exactly one of the following states:

State	Explanation
Submitted	The correction has been submitted
Assigned	The identity of the actionee has been determined (transcriber or syndicate) and allocated as owner
Unassignable	A suitable owner cannot be determined
ReportCompletion	The correction is reported as being completed
ReportRejection	The correction is reported as being rejected
ReportFailure	The correction could not be completed
CompletionReview	The reported completing is being reviewed
RejectionReview	The reported rejection is being reviewed
FailureReview	The reported failure is being reviewed
Done	The correction has been done as either Completed, Rejected or Failure

Workflow definition

This will probably be relegated to a subsidiary technical document

Explanation of columns:

State: the current state of the workflow
Action: the actions that can be taken in this state
Possible new state: the possible new state as determined by action

Workflow	State	Action	Possible new state	Note
Correction
	Submitted			the correction has been submitted
		DetermineActionee
			Assigned
			Unassignable

	Assigned			the identity of the actionee has been determined
		AmendmentResponse
			ReportCompletion
			ReportRejection
			ReportFailure
		Reassign
			Assigned

	Unassignable			a suitable actionee cannot be determined
		ManualIntervention
			Assigned
			ReportRejection

	ReportCompletion			correction completed
		SendCompletionEmail
			Completed
		ReviewCompletion
			CompletionReview

	ReportRejection			correction rejected
		SendRejectionEmail
			Completed
		ReviewRejection
			RejectionReview

	ReportFailure			correction could not be completed
		ReviewFailure
			FailureReview

	CompletionReview			review the corrections
		AcceptCompletion
			CompletionCompleted
		Return
			Submitted
			Assigned
			Unassignable

	RejectionReview			review the corrections
		AcceptRejection
			RejectionCompleted
		Return
			Submitted
			Assigned
			Unassignable

	FailureReview			review the corrections
		AcceptFailure
			FailureCompleted
		Return
			Submitted
			Assigned
			Unassignable

FreeBMD Main Page

Search engine, layout and database Copyright © 1998-2022 Free UK Genealogy CIO, a charity registered in England and Wales, Number 1167484.
We make no warranty whatsoever as to the accuracy or completeness of the FreeBMD data.
Use of the FreeBMD website is conditional upon acceptance of the Terms and Conditions