Hi Barrie Thanks for the update. It has reminded me, though, that this message can appear in other circumstances. I'm thinking of when a late entry with a post-1974 all-figures volume number has been entered into a 9z-format file (in WinBMD v6 you can switch on the "Do not Validate Districts" option for that line to allow this). I posted to the Admins list about it back in January: http://archiver.rootsweb.ancestry.com/th/read/freebmd-admins/2010-01/1264891481 As you say, there will have been warning messages when the file was saved, in this case complaining about an invalid district. The cure is to switch off district validation again to allow the file to upload. Might it be worth adding something about this to 3(j)? P.S. There seems to be a little typo in the question: "unload" instead of "upload" :-) Barrie Archer wrote on Sat, 14 Aug 2010: >barrie 10/08/14 00:19:33 > > Modified: html vol_faq.html > Log: > Add 3(j) Unable to send invalid file > >Revision Changes Path >1.144 +5 -0 UKGEN-FreeBMD/html/vol_faq.html > >Index: vol_faq.html >=================================================================== >RCS file: /home/cvs/UKGEN-FreeBMD/html/vol_faq.html,v >retrieving revision 1.143 >retrieving revision 1.144 >diff -u -r1.143 -r1.144 >--- vol_faq.html 12 Jul 2010 01:01:48 -0000 1.143 >+++ vol_faq.html 13 Aug 2010 23:19:32 -0000 1.144 >@@ -38,6 +38,7 @@ > <li><a href="#3g">Why am I being told the year in my filename >is wrong?</a> > <li><a href="#3h">How do I transcribe a special character >that is not included in the WinBMD Special Characters list?</a> > <li><a href="#3i">What do I do if the scan is incomplete?</a> >+ <li><a href="#3j">Why do I get "Unable to send invalid file"?</a> > </ol><br> > <li><a href="#4">BATCH HEADER QUERIES</a><br><br> > <ol type=a> >@@ -418,6 +419,10 @@ > <h4><a name=3i>3 (i)&nbsp;What do I do if the image shown by the scan >viewer is incomplete because it stops before the end of the >page?</a></h4> > WinBMD has a problem showing some images, so check the image using a >viewer - normally this just means going to the location from where you >downloaded the image and double clicking on it. If this solves the >problem just transcribe the missing part of the image from the viewer. >For all other problems with scans please report the problem to your >syndicate coordinator and use +BREAK in the transcription where there >are missing entries. In due course the scan will be corrected and you >will be informed so you can revise the transcription. > >+<h4><a name=3j>3 (j)&nbsp;Why do I get "Unable to send invalid file" >when trying to unload a file?</a></h4> >+You will also have got one or more messages of the form: >+<pre>Row N: Row is incomplete</pre> >+which are rows for which you have not entered anything in the Age at >Death field. If a field is empty you should transcribe ? for the field. >Enter ? for Age at Death in each of the rows given in the message. > > <h3><a name=4>4 CORRECTING BATCH HEADERS WHICH HAVE WRONG DETAILS</a></h3> > > > > > >------------------------------- >To unsubscribe from the list, please send an email to >FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >without the quotes in the subject and the body of the message -- Nowl

barrie 10/08/14 00:19:33 Modified: html vol_faq.html Log: Add 3(j) Unable to send invalid file Revision Changes Path 1.144 +5 -0 UKGEN-FreeBMD/html/vol_faq.html Index: vol_faq.html =================================================================== RCS file: /home/cvs/UKGEN-FreeBMD/html/vol_faq.html,v retrieving revision 1.143 retrieving revision 1.144 diff -u -r1.143 -r1.144 --- vol_faq.html 12 Jul 2010 01:01:48 -0000 1.143 +++ vol_faq.html 13 Aug 2010 23:19:32 -0000 1.144 @@ -38,6 +38,7 @@ <li><a href="#3g">Why am I being told the year in my filename is wrong?</a> <li><a href="#3h">How do I transcribe a special character that is not included in the WinBMD Special Characters list?</a> <li><a href="#3i">What do I do if the scan is incomplete?</a> + <li><a href="#3j">Why do I get "Unable to send invalid file"?</a> </ol><br> <li><a href="#4">BATCH HEADER QUERIES</a><br><br> <ol type=a> @@ -418,6 +419,10 @@ <h4><a name=3i>3 (i)&nbsp;What do I do if the image shown by the scan viewer is incomplete because it stops before the end of the page?</a></h4> WinBMD has a problem showing some images, so check the image using a viewer - normally this just means going to the location from where you downloaded the image and double clicking on it. If this solves the problem just transcribe the missing part of the image from the viewer. For all other problems with scans please report the problem to your syndicate coordinator and use +BREAK in the transcription where there are missing entries. In due course the scan will be corrected and you will be informed so you can revise the transcription. +<h4><a name=3j>3 (j)&nbsp;Why do I get "Unable to send invalid file" when trying to unload a file?</a></h4> +You will also have got one or more messages of the form: +<pre>Row N: Row is incomplete</pre> +which are rows for which you have not entered anything in the Age at Death field. If a field is empty you should transcribe ? for the field. Enter ? for Age at Death in each of the rows given in the message. <h3><a name=4>4 CORRECTING BATCH HEADERS WHICH HAVE WRONG DETAILS</a></h3>

Hello Barrie, If you are saying that it has always been the case that a file uploaded before a person was added to a syndicate, never counted to the syndicate totals then I apologise. I must say this was not my understanding of the situation. It does raise the question why has this not been rectified as it must be a simple thing to do. Regards Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie Sent: 07 August 2010 11:58 To: freebmd-syndicates@rootsweb.com Subject: Re: RE: Non-syndicate transcriptions Brian, The "proposal" was to make the warning into an error (my email "Checking transcriptions" 13 Jul 2010 08:42:19). This has now been shelved (my email "Non-syndicate transcriptions" 28 Jul 2010 17:08:21) because it would inconvenience you (your email (to Admins) "Re Checking transcriptions" 19 Jul 2010 11:36:52) although about 8 other coordinators were happy and, indeed, some commented it would make less work for them. It is somewhat ungracious, therefore, for you to say that your comments have been ignored. The discussion in this thread has been over the warning (your email "RE: Non-syndicate transcriptions" 28 Jul 2010 19:14:52) but it is difficult to understand how this warning makes your life materially more difficult. All you have to do is tell your new subscribers to ignore the warning - presumably you have a template email that just needs to be changed once. I have already suggested this (my email "Re: RE: RE: RE: Non-syndicate transcriptions" 01 Aug 2010 00:35:36). Of course, the trial transcriptions of your new transcribers will not be counted as being for your syndicate (unless they upload them again after they have been added to your syndicate) but this is the status quo and, in any case, you have repeatedly said it is not an issue for you. Barrie On 19:59, Brian Smart wrote: > Hello Allan, > It seems to me that everybody can find reasons to make my life more > difficult but can't find a solution that suits everybody! > I don't know why we were asked to comment on the proposal if the comments > were going to be ignored. > > Brian Smart > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Allan Raymond > Sent: 06 August 2010 13:11 > To: freebmd-syndicates@rootsweb.com > Subject: Re: Non-syndicate transcriptions > > Brian > > This is an invalid statement, I can say with certainty that not all file > headers include an email address and even if one exists it may not be a > valid address or up to date address. > > Also some volunteers belong to more than syndicate, so by your suggestion > some Coordinators are going to be inconvenienced by automatic emails which > may not apply to them. > > Allan Raymond > > ----- Original Message ----- > From: Brian Smart > To: freebmd-syndicates@rootsweb.com > Sent: Tuesday, August 03, 2010 3:00 PM > Subject: RE: RE: RE: RE: Non-syndicate transcriptions > > > Hello Barrie, > All file headers include an email address that can be checked to find the > relevant syndicate. From this you can send an email to the associated > coordinator advising the problem. All this can be automated so only the > relevant coordinator has to take action. > This overcomes all of your concerns. > > Brian Smart > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 01 August 2010 00:36 > To: freebmd-syndicates@rootsweb.com > Subject: Re: RE: RE: RE: Non-syndicate transcriptions > > Brian, > > You seem to be under the misapprehension that there are several checks; > you said: > > The problem exists because the checks that are performed includes one > that > checks if the uploaded file is one that has the transcriber signed up > to > a > specific syndicate. If this part of the check was removed there would > be > no > problem. > > In fact there is only _one_ check which is that the transcriber is a > member of a syndicate transcribing the quarter. Failing this single > check can be caused by: > > * transcribers not having been added to the syndicate they are > transcribing for > o because the coordinator has forgotten to add them > o because they are not added until they have done their first > transcription > * transcribers transcribing the wrong quarter > * transcribers specifying the wrong year or quarter or event in the > file > > A short while ago I did a check on syndicate membership and found > hundreds of instances of transcriptions that erroneously had no > syndicate because the coordinator had forgotten to add the transcriber > to their syndicate (you had one such transcriber who I notified you > about). Such transcriptions would be incorrectly handled in the > instances I gave in my previous posting, affecting _all_ coordinators > and the system. It took a good deal of work to sort out (indeed it is > still ongoing) and it is important that we do what we can to avoid > getting into the same situation again by preventing the error at source. > > You complain that this check results in more work for you, but all you > have to do is instruct your new transcribers to ignore the warning on > their first upload. > > Barrie > > On 19:59, Brian Smart wrote: > > Hello Barrie, > > Re: > > "The check merely indicates the problem exists; changing the check won't > > make the problem go away. The issue is, I think, whether a non-syndicate > > transcription is a problem so let me expand on what I said in my > > original posting." > > > > The problem exists because the checks that are performed includes one > that > > checks if the uploaded file is one that has the transcriber signed up to > a > > specific syndicate. If this part of the check was removed there would be > no > > problem. > > > > > > Re: > > "* The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > > list shows the syndicate of the file; this allows coordinators to > > see which files they need to be concerned with" > > > > I seem to remember that the suspect files report used to indicate both > > syndicates before this latest change. What is the problem with that? > > > > Re: > > "* Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > > the option for the results to be dependent on the syndicate of the > > file (e.g. list only files transcribed for a particular syndicate) > > > > While this is true, the only coordinators affected by this are those > like > me > > who do not add the person to the syndicate until they have uploaded a > file. > > I am quite happy with that situation. > > > > > > Re: > > "* The coordinator version of Show File > > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > > coordinators to download the file if it has been transcribed for > > their syndicate." > > > > > > True but again it is only coordinators like me that this affects, thus > this > > is not a valid reason to change the system. > > > > > > Re: > > * When the database is created the syndicate of the file is used to > > determine of there is duplication within a syndicate; an entry is > > not considered to be double keyed if both transcriptions are > > within a syndicate > > > > This is a minor short term problem and not a reason to cause those > > transcribers like me who do not want the system changed. > > > > > > Re: > > > > "So it is quite important that the syndicate a file is transcribed for > is > > correct. If it isn't coordinators will be put to extra work and so I > > don't understand why not having a syndicate could be considered > acceptable." > > > > > > Again the coordinators affected are those like me and I am happy to > accept > > the situation. For me the result is less work not more. > > > > > > Please remove this part of the checking process. > > > > Brian Smart > > > > > > > > > > -----Original Message----- > > From: freebmd-syndicates-bounces@rootsweb.com > > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > > Sent: 29 July 2010 17:48 > > To: freebmd-syndicates@rootsweb.com > > Subject: Re: RE: RE: Non-syndicate transcriptions > > > > Brian, > > > > The check merely indicates the problem exists; changing the check won't > > make the problem go away. The issue is, I think, whether a non-syndicate > > transcription is a problem so let me expand on what I said in my > > original posting. > > > > When a file is uploaded the system makes a decision about what syndicate > > it has been transcribed for and that syndicate (or syndicates if it is > > ambiguous) is recorded with the file. The information about the > > syndicate is used in (at least) the following ways: > > > > * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > > list shows the syndicate of the file; this allows coordinators to > > see which files they need to be concerned with > > * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > > the option for the results to be dependent on the syndicate of the > > file (e.g. list only files transcribed for a particular syndicate) > > * The coordinator version of Show File > > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > > coordinators to download the file if it has been transcribed for > > their syndicate > > * When the database is created the syndicate of the file is used to > > determine of there is duplication within a syndicate; an entry is > > not considered to be double keyed if both transcriptions are > > within a syndicate > > > > So it is quite important that the syndicate a file is transcribed for is > > correct. If it isn't coordinators will be put to extra work and so I > > don't understand why not having a syndicate could be considered > acceptable. > > > > Regards > > > > Barrie > > > > On 19:59, Brian Smart wrote: > > > >> Hello Barrie, > >> Surely the checking system needs to be changed then the problem would > not > >> exist. > >> Regards > >> > >> Brian Smart > >> > >> > >> -----Original Message----- > >> From: freebmd-syndicates-bounces@rootsweb.com > >> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > >> Sent: 29 July 2010 00:15 > >> To: freebmd-syndicates@rootsweb.com > >> Subject: Re: RE: Non-syndicate transcriptions > >> > >> Brian, > >> > >> The clause you mention is not part of the warning; it was part of my > >> explanation of the possible causes for the warning. > >> > >> The system cannot normally differentiate between these these three > >> causes for the warning, it just knows that the file has not been marked > >> as transcribed for a syndicate. > >> > >> Barrie > >> > >> On 19:59, Brian Smart wrote: > >> > >> > >>> Hello Barrie, > >>> Why not remove the cause: "* they have not been added to the syndicate > >>> > >>> > >> they > >> > >> > >>> are transcribing for" from this Warning/error and then the other two > >>> possible causes can be errors. > >>> I fail to see why the fact that the person has not been added to the > >>> syndicate at the time of the upload should constitute a problem in any > >>> > >>> > >> way. > >> > >> > >>> Regards > >>> > >>> Brian Smart > >>> > >>> -----Original Message----- > >>> From: freebmd-syndicates-bounces@rootsweb.com > >>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > >>> Sent: 28 July 2010 17:08 > >>> To: freebmd-syndicates@rootsweb.com > >>> Subject: Non-syndicate transcriptions > >>> > >>> The error that caused transcriptions to erroneous get reported as > _not_ > >>> being done within a user's syndicate has now been corrected. If users > >>> get the warning > >>> > >>> /You do not appear to be a member of a syndicate transcribing this > >>> quarter. Please check you have the correct Year, Quarter and Event > >>> or contact your syndicate coordinator./ > >>> > >>> the most likely causes are: > >>> > >>> * they have not been added to the syndicate they are transcribing > for > >>> * they have transcribed the wrong quarter > >>> * they have specified the wrong year or quarter or event in the > file > >>> > >>> Please note that files identified by this warning will not be > allocated > >>> to any syndicate and therefore coordinators will not be able to use > >>> coordinator facilities (such as UploadReport for a particular > syndicate > >>> or downloading the file) for such a file. If the issue is that the > >>> transcriber has not been added to the syndicate, it should be possible > >>> to correct this by the transcriber uploading the file again (once the > >>> transcriber has been added to the syndicate). You can use > >>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a > >>> file has been transcribed for. > >>> > >>> Because of feedback received this will remain a warning rather than > >>> being upgraded to an error. > >>> > >>> Barrie > >>> > >>> > >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > >>> > >>> ------------------------------- > >>> To unsubscribe from the list, please send an email to > >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > >>> > >>> > >> without > >> > >> > >>> the quotes in the subject and the body of the message > >>> > >>> > >>> > >>> > >>> > >>> > >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > >> > >> ------------------------------- > >> To unsubscribe from the list, please send an email to > >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > >> > > without > > > >> the quotes in the subject and the body of the message > >> > >> > >> > >> > >> > > > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > > > ------------------------------- > > To unsubscribe from the list, please send an email to > > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without > > the quotes in the subject and the body of the message > > > > > > > > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without > the quotes in the subject and the body of the message > > > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Brian, The "proposal" was to make the warning into an error (my email "Checking transcriptions" 13 Jul 2010 08:42:19). This has now been shelved (my email "Non-syndicate transcriptions" 28 Jul 2010 17:08:21) because it would inconvenience you (your email (to Admins) "Re Checking transcriptions" 19 Jul 2010 11:36:52) although about 8 other coordinators were happy and, indeed, some commented it would make less work for them. It is somewhat ungracious, therefore, for you to say that your comments have been ignored. The discussion in this thread has been over the warning (your email "RE: Non-syndicate transcriptions" 28 Jul 2010 19:14:52) but it is difficult to understand how this warning makes your life materially more difficult. All you have to do is tell your new subscribers to ignore the warning - presumably you have a template email that just needs to be changed once. I have already suggested this (my email "Re: RE: RE: RE: Non-syndicate transcriptions" 01 Aug 2010 00:35:36). Of course, the trial transcriptions of your new transcribers will not be counted as being for your syndicate (unless they upload them again after they have been added to your syndicate) but this is the status quo and, in any case, you have repeatedly said it is not an issue for you. Barrie On 19:59, Brian Smart wrote: > Hello Allan, > It seems to me that everybody can find reasons to make my life more > difficult but can't find a solution that suits everybody! > I don't know why we were asked to comment on the proposal if the comments > were going to be ignored. > > Brian Smart > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Allan Raymond > Sent: 06 August 2010 13:11 > To: freebmd-syndicates@rootsweb.com > Subject: Re: Non-syndicate transcriptions > > Brian > > This is an invalid statement, I can say with certainty that not all file > headers include an email address and even if one exists it may not be a > valid address or up to date address. > > Also some volunteers belong to more than syndicate, so by your suggestion > some Coordinators are going to be inconvenienced by automatic emails which > may not apply to them. > > Allan Raymond > > ----- Original Message ----- > From: Brian Smart > To: freebmd-syndicates@rootsweb.com > Sent: Tuesday, August 03, 2010 3:00 PM > Subject: RE: RE: RE: RE: Non-syndicate transcriptions > > > Hello Barrie, > All file headers include an email address that can be checked to find the > relevant syndicate. From this you can send an email to the associated > coordinator advising the problem. All this can be automated so only the > relevant coordinator has to take action. > This overcomes all of your concerns. > > Brian Smart > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 01 August 2010 00:36 > To: freebmd-syndicates@rootsweb.com > Subject: Re: RE: RE: RE: Non-syndicate transcriptions > > Brian, > > You seem to be under the misapprehension that there are several checks; > you said: > > The problem exists because the checks that are performed includes one > that > checks if the uploaded file is one that has the transcriber signed up > to > a > specific syndicate. If this part of the check was removed there would > be > no > problem. > > In fact there is only _one_ check which is that the transcriber is a > member of a syndicate transcribing the quarter. Failing this single > check can be caused by: > > * transcribers not having been added to the syndicate they are > transcribing for > o because the coordinator has forgotten to add them > o because they are not added until they have done their first > transcription > * transcribers transcribing the wrong quarter > * transcribers specifying the wrong year or quarter or event in the > file > > A short while ago I did a check on syndicate membership and found > hundreds of instances of transcriptions that erroneously had no > syndicate because the coordinator had forgotten to add the transcriber > to their syndicate (you had one such transcriber who I notified you > about). Such transcriptions would be incorrectly handled in the > instances I gave in my previous posting, affecting _all_ coordinators > and the system. It took a good deal of work to sort out (indeed it is > still ongoing) and it is important that we do what we can to avoid > getting into the same situation again by preventing the error at source. > > You complain that this check results in more work for you, but all you > have to do is instruct your new transcribers to ignore the warning on > their first upload. > > Barrie > > On 19:59, Brian Smart wrote: > > Hello Barrie, > > Re: > > "The check merely indicates the problem exists; changing the check won't > > make the problem go away. The issue is, I think, whether a non-syndicate > > transcription is a problem so let me expand on what I said in my > > original posting." > > > > The problem exists because the checks that are performed includes one > that > > checks if the uploaded file is one that has the transcriber signed up to > a > > specific syndicate. If this part of the check was removed there would be > no > > problem. > > > > > > Re: > > "* The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > > list shows the syndicate of the file; this allows coordinators to > > see which files they need to be concerned with" > > > > I seem to remember that the suspect files report used to indicate both > > syndicates before this latest change. What is the problem with that? > > > > Re: > > "* Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > > the option for the results to be dependent on the syndicate of the > > file (e.g. list only files transcribed for a particular syndicate) > > > > While this is true, the only coordinators affected by this are those > like > me > > who do not add the person to the syndicate until they have uploaded a > file. > > I am quite happy with that situation. > > > > > > Re: > > "* The coordinator version of Show File > > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > > coordinators to download the file if it has been transcribed for > > their syndicate." > > > > > > True but again it is only coordinators like me that this affects, thus > this > > is not a valid reason to change the system. > > > > > > Re: > > * When the database is created the syndicate of the file is used to > > determine of there is duplication within a syndicate; an entry is > > not considered to be double keyed if both transcriptions are > > within a syndicate > > > > This is a minor short term problem and not a reason to cause those > > transcribers like me who do not want the system changed. > > > > > > Re: > > > > "So it is quite important that the syndicate a file is transcribed for > is > > correct. If it isn't coordinators will be put to extra work and so I > > don't understand why not having a syndicate could be considered > acceptable." > > > > > > Again the coordinators affected are those like me and I am happy to > accept > > the situation. For me the result is less work not more. > > > > > > Please remove this part of the checking process. > > > > Brian Smart > > > > > > > > > > -----Original Message----- > > From: freebmd-syndicates-bounces@rootsweb.com > > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > > Sent: 29 July 2010 17:48 > > To: freebmd-syndicates@rootsweb.com > > Subject: Re: RE: RE: Non-syndicate transcriptions > > > > Brian, > > > > The check merely indicates the problem exists; changing the check won't > > make the problem go away. The issue is, I think, whether a non-syndicate > > transcription is a problem so let me expand on what I said in my > > original posting. > > > > When a file is uploaded the system makes a decision about what syndicate > > it has been transcribed for and that syndicate (or syndicates if it is > > ambiguous) is recorded with the file. The information about the > > syndicate is used in (at least) the following ways: > > > > * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > > list shows the syndicate of the file; this allows coordinators to > > see which files they need to be concerned with > > * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > > the option for the results to be dependent on the syndicate of the > > file (e.g. list only files transcribed for a particular syndicate) > > * The coordinator version of Show File > > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > > coordinators to download the file if it has been transcribed for > > their syndicate > > * When the database is created the syndicate of the file is used to > > determine of there is duplication within a syndicate; an entry is > > not considered to be double keyed if both transcriptions are > > within a syndicate > > > > So it is quite important that the syndicate a file is transcribed for is > > correct. If it isn't coordinators will be put to extra work and so I > > don't understand why not having a syndicate could be considered > acceptable. > > > > Regards > > > > Barrie > > > > On 19:59, Brian Smart wrote: > > > >> Hello Barrie, > >> Surely the checking system needs to be changed then the problem would > not > >> exist. > >> Regards > >> > >> Brian Smart > >> > >> > >> -----Original Message----- > >> From: freebmd-syndicates-bounces@rootsweb.com > >> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > >> Sent: 29 July 2010 00:15 > >> To: freebmd-syndicates@rootsweb.com > >> Subject: Re: RE: Non-syndicate transcriptions > >> > >> Brian, > >> > >> The clause you mention is not part of the warning; it was part of my > >> explanation of the possible causes for the warning. > >> > >> The system cannot normally differentiate between these these three > >> causes for the warning, it just knows that the file has not been marked > >> as transcribed for a syndicate. > >> > >> Barrie > >> > >> On 19:59, Brian Smart wrote: > >> > >> > >>> Hello Barrie, > >>> Why not remove the cause: "* they have not been added to the syndicate > >>> > >>> > >> they > >> > >> > >>> are transcribing for" from this Warning/error and then the other two > >>> possible causes can be errors. > >>> I fail to see why the fact that the person has not been added to the > >>> syndicate at the time of the upload should constitute a problem in any > >>> > >>> > >> way. > >> > >> > >>> Regards > >>> > >>> Brian Smart > >>> > >>> -----Original Message----- > >>> From: freebmd-syndicates-bounces@rootsweb.com > >>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > >>> Sent: 28 July 2010 17:08 > >>> To: freebmd-syndicates@rootsweb.com > >>> Subject: Non-syndicate transcriptions > >>> > >>> The error that caused transcriptions to erroneous get reported as > _not_ > >>> being done within a user's syndicate has now been corrected. If users > >>> get the warning > >>> > >>> /You do not appear to be a member of a syndicate transcribing this > >>> quarter. Please check you have the correct Year, Quarter and Event > >>> or contact your syndicate coordinator./ > >>> > >>> the most likely causes are: > >>> > >>> * they have not been added to the syndicate they are transcribing > for > >>> * they have transcribed the wrong quarter > >>> * they have specified the wrong year or quarter or event in the > file > >>> > >>> Please note that files identified by this warning will not be > allocated > >>> to any syndicate and therefore coordinators will not be able to use > >>> coordinator facilities (such as UploadReport for a particular > syndicate > >>> or downloading the file) for such a file. If the issue is that the > >>> transcriber has not been added to the syndicate, it should be possible > >>> to correct this by the transcriber uploading the file again (once the > >>> transcriber has been added to the syndicate). You can use > >>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a > >>> file has been transcribed for. > >>> > >>> Because of feedback received this will remain a warning rather than > >>> being upgraded to an error. > >>> > >>> Barrie > >>> > >>> > >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > >>> > >>> ------------------------------- > >>> To unsubscribe from the list, please send an email to > >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > >>> > >>> > >> without > >> > >> > >>> the quotes in the subject and the body of the message > >>> > >>> > >>> > >>> > >>> > >>> > >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > >> > >> ------------------------------- > >> To unsubscribe from the list, please send an email to > >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > >> > > without > > > >> the quotes in the subject and the body of the message > >> > >> > >> > >> > >> > > > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > > > ------------------------------- > > To unsubscribe from the list, please send an email to > > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without > > the quotes in the subject and the body of the message > > > > > > > > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without > the quotes in the subject and the body of the message > > > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner--

Hello Allan, It seems to me that everybody can find reasons to make my life more difficult but can't find a solution that suits everybody! I don't know why we were asked to comment on the proposal if the comments were going to be ignored. Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Allan Raymond Sent: 06 August 2010 13:11 To: freebmd-syndicates@rootsweb.com Subject: Re: Non-syndicate transcriptions Brian This is an invalid statement, I can say with certainty that not all file headers include an email address and even if one exists it may not be a valid address or up to date address. Also some volunteers belong to more than syndicate, so by your suggestion some Coordinators are going to be inconvenienced by automatic emails which may not apply to them. Allan Raymond ----- Original Message ----- From: Brian Smart To: freebmd-syndicates@rootsweb.com Sent: Tuesday, August 03, 2010 3:00 PM Subject: RE: RE: RE: RE: Non-syndicate transcriptions Hello Barrie, All file headers include an email address that can be checked to find the relevant syndicate. From this you can send an email to the associated coordinator advising the problem. All this can be automated so only the relevant coordinator has to take action. This overcomes all of your concerns. Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie Sent: 01 August 2010 00:36 To: freebmd-syndicates@rootsweb.com Subject: Re: RE: RE: RE: Non-syndicate transcriptions Brian, You seem to be under the misapprehension that there are several checks; you said: The problem exists because the checks that are performed includes one that checks if the uploaded file is one that has the transcriber signed up to a specific syndicate. If this part of the check was removed there would be no problem. In fact there is only _one_ check which is that the transcriber is a member of a syndicate transcribing the quarter. Failing this single check can be caused by: * transcribers not having been added to the syndicate they are transcribing for o because the coordinator has forgotten to add them o because they are not added until they have done their first transcription * transcribers transcribing the wrong quarter * transcribers specifying the wrong year or quarter or event in the file A short while ago I did a check on syndicate membership and found hundreds of instances of transcriptions that erroneously had no syndicate because the coordinator had forgotten to add the transcriber to their syndicate (you had one such transcriber who I notified you about). Such transcriptions would be incorrectly handled in the instances I gave in my previous posting, affecting _all_ coordinators and the system. It took a good deal of work to sort out (indeed it is still ongoing) and it is important that we do what we can to avoid getting into the same situation again by preventing the error at source. You complain that this check results in more work for you, but all you have to do is instruct your new transcribers to ignore the warning on their first upload. Barrie On 19:59, Brian Smart wrote: > Hello Barrie, > Re: > "The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting." > > The problem exists because the checks that are performed includes one that > checks if the uploaded file is one that has the transcriber signed up to a > specific syndicate. If this part of the check was removed there would be no > problem. > > > Re: > "* The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with" > > I seem to remember that the suspect files report used to indicate both > syndicates before this latest change. What is the problem with that? > > Re: > "* Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > > While this is true, the only coordinators affected by this are those like me > who do not add the person to the syndicate until they have uploaded a file. > I am quite happy with that situation. > > > Re: > "* The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate." > > > True but again it is only coordinators like me that this affects, thus this > is not a valid reason to change the system. > > > Re: > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > This is a minor short term problem and not a reason to cause those > transcribers like me who do not want the system changed. > > > Re: > > "So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable." > > > Again the coordinators affected are those like me and I am happy to accept > the situation. For me the result is less work not more. > > > Please remove this part of the checking process. > > Brian Smart > > > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 29 July 2010 17:48 > To: freebmd-syndicates@rootsweb.com > Subject: Re: RE: RE: Non-syndicate transcriptions > > Brian, > > The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting. > > When a file is uploaded the system makes a decision about what syndicate > it has been transcribed for and that syndicate (or syndicates if it is > ambiguous) is recorded with the file. The information about the > syndicate is used in (at least) the following ways: > > * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with > * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > * The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable. > > Regards > > Barrie > > On 19:59, Brian Smart wrote: > >> Hello Barrie, >> Surely the checking system needs to be changed then the problem would not >> exist. >> Regards >> >> Brian Smart >> >> >> -----Original Message----- >> From: freebmd-syndicates-bounces@rootsweb.com >> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >> Sent: 29 July 2010 00:15 >> To: freebmd-syndicates@rootsweb.com >> Subject: Re: RE: Non-syndicate transcriptions >> >> Brian, >> >> The clause you mention is not part of the warning; it was part of my >> explanation of the possible causes for the warning. >> >> The system cannot normally differentiate between these these three >> causes for the warning, it just knows that the file has not been marked >> as transcribed for a syndicate. >> >> Barrie >> >> On 19:59, Brian Smart wrote: >> >> >>> Hello Barrie, >>> Why not remove the cause: "* they have not been added to the syndicate >>> >>> >> they >> >> >>> are transcribing for" from this Warning/error and then the other two >>> possible causes can be errors. >>> I fail to see why the fact that the person has not been added to the >>> syndicate at the time of the upload should constitute a problem in any >>> >>> >> way. >> >> >>> Regards >>> >>> Brian Smart >>> >>> -----Original Message----- >>> From: freebmd-syndicates-bounces@rootsweb.com >>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>> Sent: 28 July 2010 17:08 >>> To: freebmd-syndicates@rootsweb.com >>> Subject: Non-syndicate transcriptions >>> >>> The error that caused transcriptions to erroneous get reported as _not_ >>> being done within a user's syndicate has now been corrected. If users >>> get the warning >>> >>> /You do not appear to be a member of a syndicate transcribing this >>> quarter. Please check you have the correct Year, Quarter and Event >>> or contact your syndicate coordinator./ >>> >>> the most likely causes are: >>> >>> * they have not been added to the syndicate they are transcribing for >>> * they have transcribed the wrong quarter >>> * they have specified the wrong year or quarter or event in the file >>> >>> Please note that files identified by this warning will not be allocated >>> to any syndicate and therefore coordinators will not be able to use >>> coordinator facilities (such as UploadReport for a particular syndicate >>> or downloading the file) for such a file. If the issue is that the >>> transcriber has not been added to the syndicate, it should be possible >>> to correct this by the transcriber uploading the file again (once the >>> transcriber has been added to the syndicate). You can use >>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a >>> file has been transcribed for. >>> >>> Because of feedback received this will remain a warning rather than >>> being upgraded to an error. >>> >>> Barrie >>> >>> >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>> >>> ------------------------------- >>> To unsubscribe from the list, please send an email to >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>> >>> >> without >> >> >>> the quotes in the subject and the body of the message >>> >>> >>> >>> >>> >>> >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >> >> ------------------------------- >> To unsubscribe from the list, please send an email to >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >> > without > >> the quotes in the subject and the body of the message >> >> >> >> >> > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Brian This is an invalid statement, I can say with certainty that not all file headers include an email address and even if one exists it may not be a valid address or up to date address. Also some volunteers belong to more than syndicate, so by your suggestion some Coordinators are going to be inconvenienced by automatic emails which may not apply to them. Allan Raymond ----- Original Message ----- From: Brian Smart To: freebmd-syndicates@rootsweb.com Sent: Tuesday, August 03, 2010 3:00 PM Subject: RE: RE: RE: RE: Non-syndicate transcriptions Hello Barrie, All file headers include an email address that can be checked to find the relevant syndicate. From this you can send an email to the associated coordinator advising the problem. All this can be automated so only the relevant coordinator has to take action. This overcomes all of your concerns. Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie Sent: 01 August 2010 00:36 To: freebmd-syndicates@rootsweb.com Subject: Re: RE: RE: RE: Non-syndicate transcriptions Brian, You seem to be under the misapprehension that there are several checks; you said: The problem exists because the checks that are performed includes one that checks if the uploaded file is one that has the transcriber signed up to a specific syndicate. If this part of the check was removed there would be no problem. In fact there is only _one_ check which is that the transcriber is a member of a syndicate transcribing the quarter. Failing this single check can be caused by: * transcribers not having been added to the syndicate they are transcribing for o because the coordinator has forgotten to add them o because they are not added until they have done their first transcription * transcribers transcribing the wrong quarter * transcribers specifying the wrong year or quarter or event in the file A short while ago I did a check on syndicate membership and found hundreds of instances of transcriptions that erroneously had no syndicate because the coordinator had forgotten to add the transcriber to their syndicate (you had one such transcriber who I notified you about). Such transcriptions would be incorrectly handled in the instances I gave in my previous posting, affecting _all_ coordinators and the system. It took a good deal of work to sort out (indeed it is still ongoing) and it is important that we do what we can to avoid getting into the same situation again by preventing the error at source. You complain that this check results in more work for you, but all you have to do is instruct your new transcribers to ignore the warning on their first upload. Barrie On 19:59, Brian Smart wrote: > Hello Barrie, > Re: > "The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting." > > The problem exists because the checks that are performed includes one that > checks if the uploaded file is one that has the transcriber signed up to a > specific syndicate. If this part of the check was removed there would be no > problem. > > > Re: > "* The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with" > > I seem to remember that the suspect files report used to indicate both > syndicates before this latest change. What is the problem with that? > > Re: > "* Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > > While this is true, the only coordinators affected by this are those like me > who do not add the person to the syndicate until they have uploaded a file. > I am quite happy with that situation. > > > Re: > "* The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate." > > > True but again it is only coordinators like me that this affects, thus this > is not a valid reason to change the system. > > > Re: > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > This is a minor short term problem and not a reason to cause those > transcribers like me who do not want the system changed. > > > Re: > > "So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable." > > > Again the coordinators affected are those like me and I am happy to accept > the situation. For me the result is less work not more. > > > Please remove this part of the checking process. > > Brian Smart > > > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 29 July 2010 17:48 > To: freebmd-syndicates@rootsweb.com > Subject: Re: RE: RE: Non-syndicate transcriptions > > Brian, > > The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting. > > When a file is uploaded the system makes a decision about what syndicate > it has been transcribed for and that syndicate (or syndicates if it is > ambiguous) is recorded with the file. The information about the > syndicate is used in (at least) the following ways: > > * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with > * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > * The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable. > > Regards > > Barrie > > On 19:59, Brian Smart wrote: > >> Hello Barrie, >> Surely the checking system needs to be changed then the problem would not >> exist. >> Regards >> >> Brian Smart >> >> >> -----Original Message----- >> From: freebmd-syndicates-bounces@rootsweb.com >> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >> Sent: 29 July 2010 00:15 >> To: freebmd-syndicates@rootsweb.com >> Subject: Re: RE: Non-syndicate transcriptions >> >> Brian, >> >> The clause you mention is not part of the warning; it was part of my >> explanation of the possible causes for the warning. >> >> The system cannot normally differentiate between these these three >> causes for the warning, it just knows that the file has not been marked >> as transcribed for a syndicate. >> >> Barrie >> >> On 19:59, Brian Smart wrote: >> >> >>> Hello Barrie, >>> Why not remove the cause: "* they have not been added to the syndicate >>> >>> >> they >> >> >>> are transcribing for" from this Warning/error and then the other two >>> possible causes can be errors. >>> I fail to see why the fact that the person has not been added to the >>> syndicate at the time of the upload should constitute a problem in any >>> >>> >> way. >> >> >>> Regards >>> >>> Brian Smart >>> >>> -----Original Message----- >>> From: freebmd-syndicates-bounces@rootsweb.com >>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>> Sent: 28 July 2010 17:08 >>> To: freebmd-syndicates@rootsweb.com >>> Subject: Non-syndicate transcriptions >>> >>> The error that caused transcriptions to erroneous get reported as _not_ >>> being done within a user's syndicate has now been corrected. If users >>> get the warning >>> >>> /You do not appear to be a member of a syndicate transcribing this >>> quarter. Please check you have the correct Year, Quarter and Event >>> or contact your syndicate coordinator./ >>> >>> the most likely causes are: >>> >>> * they have not been added to the syndicate they are transcribing for >>> * they have transcribed the wrong quarter >>> * they have specified the wrong year or quarter or event in the file >>> >>> Please note that files identified by this warning will not be allocated >>> to any syndicate and therefore coordinators will not be able to use >>> coordinator facilities (such as UploadReport for a particular syndicate >>> or downloading the file) for such a file. If the issue is that the >>> transcriber has not been added to the syndicate, it should be possible >>> to correct this by the transcriber uploading the file again (once the >>> transcriber has been added to the syndicate). You can use >>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a >>> file has been transcribed for. >>> >>> Because of feedback received this will remain a warning rather than >>> being upgraded to an error. >>> >>> Barrie >>> >>> >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>> >>> ------------------------------- >>> To unsubscribe from the list, please send an email to >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>> >>> >> without >> >> >>> the quotes in the subject and the body of the message >>> >>> >>> >>> >>> >>> >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >> >> ------------------------------- >> To unsubscribe from the list, please send an email to >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >> > without > >> the quotes in the subject and the body of the message >> >> >> >> >> > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

As expected I had none to delete, Allan. Regards, Ted Southcombe . ----- Original Message ----- From: "Allan Raymond" <allan_raymond@btinternet.com> To: <freebmd-syndicates@rootsweb.com> Sent: Wednesday, August 04, 2010 3:01 PM Subject: Deletion of Volunteers From FreeBMD > > A quick favour to ask Syndicate Coordinators. > > Could you please have a check of "Current Submitters" window on your > Maintain Syndicate page and delete any volunteers shown with the following > message format? > > ** ID (e.g XYZ123) - DELETED ** ** Please Remove** ID (e.g XYZ123) > > The deleted volunteers will be collected together and shown at the end of > the complete list of volunteers. > > Actually deleting the volunteers will assist my administration aspects. > > Thanks > > Allan Raymond > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without the quotes in the subject and the body of the message >

A quick favour to ask Syndicate Coordinators. Could you please have a check of "Current Submitters" window on your Maintain Syndicate page and delete any volunteers shown with the following message format? ** ID (e.g XYZ123) - DELETED ** ** Please Remove** ID (e.g XYZ123) The deleted volunteers will be collected together and shown at the end of the complete list of volunteers. Actually deleting the volunteers will assist my administration aspects. Thanks Allan Raymond

Hello Barrie, All file headers include an email address that can be checked to find the relevant syndicate. From this you can send an email to the associated coordinator advising the problem. All this can be automated so only the relevant coordinator has to take action. This overcomes all of your concerns. Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie Sent: 01 August 2010 00:36 To: freebmd-syndicates@rootsweb.com Subject: Re: RE: RE: RE: Non-syndicate transcriptions Brian, You seem to be under the misapprehension that there are several checks; you said: The problem exists because the checks that are performed includes one that checks if the uploaded file is one that has the transcriber signed up to a specific syndicate. If this part of the check was removed there would be no problem. In fact there is only _one_ check which is that the transcriber is a member of a syndicate transcribing the quarter. Failing this single check can be caused by: * transcribers not having been added to the syndicate they are transcribing for o because the coordinator has forgotten to add them o because they are not added until they have done their first transcription * transcribers transcribing the wrong quarter * transcribers specifying the wrong year or quarter or event in the file A short while ago I did a check on syndicate membership and found hundreds of instances of transcriptions that erroneously had no syndicate because the coordinator had forgotten to add the transcriber to their syndicate (you had one such transcriber who I notified you about). Such transcriptions would be incorrectly handled in the instances I gave in my previous posting, affecting _all_ coordinators and the system. It took a good deal of work to sort out (indeed it is still ongoing) and it is important that we do what we can to avoid getting into the same situation again by preventing the error at source. You complain that this check results in more work for you, but all you have to do is instruct your new transcribers to ignore the warning on their first upload. Barrie On 19:59, Brian Smart wrote: > Hello Barrie, > Re: > "The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting." > > The problem exists because the checks that are performed includes one that > checks if the uploaded file is one that has the transcriber signed up to a > specific syndicate. If this part of the check was removed there would be no > problem. > > > Re: > "* The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with" > > I seem to remember that the suspect files report used to indicate both > syndicates before this latest change. What is the problem with that? > > Re: > "* Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > > While this is true, the only coordinators affected by this are those like me > who do not add the person to the syndicate until they have uploaded a file. > I am quite happy with that situation. > > > Re: > "* The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate." > > > True but again it is only coordinators like me that this affects, thus this > is not a valid reason to change the system. > > > Re: > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > This is a minor short term problem and not a reason to cause those > transcribers like me who do not want the system changed. > > > Re: > > "So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable." > > > Again the coordinators affected are those like me and I am happy to accept > the situation. For me the result is less work not more. > > > Please remove this part of the checking process. > > Brian Smart > > > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 29 July 2010 17:48 > To: freebmd-syndicates@rootsweb.com > Subject: Re: RE: RE: Non-syndicate transcriptions > > Brian, > > The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting. > > When a file is uploaded the system makes a decision about what syndicate > it has been transcribed for and that syndicate (or syndicates if it is > ambiguous) is recorded with the file. The information about the > syndicate is used in (at least) the following ways: > > * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with > * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > * The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable. > > Regards > > Barrie > > On 19:59, Brian Smart wrote: > >> Hello Barrie, >> Surely the checking system needs to be changed then the problem would not >> exist. >> Regards >> >> Brian Smart >> >> >> -----Original Message----- >> From: freebmd-syndicates-bounces@rootsweb.com >> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >> Sent: 29 July 2010 00:15 >> To: freebmd-syndicates@rootsweb.com >> Subject: Re: RE: Non-syndicate transcriptions >> >> Brian, >> >> The clause you mention is not part of the warning; it was part of my >> explanation of the possible causes for the warning. >> >> The system cannot normally differentiate between these these three >> causes for the warning, it just knows that the file has not been marked >> as transcribed for a syndicate. >> >> Barrie >> >> On 19:59, Brian Smart wrote: >> >> >>> Hello Barrie, >>> Why not remove the cause: "* they have not been added to the syndicate >>> >>> >> they >> >> >>> are transcribing for" from this Warning/error and then the other two >>> possible causes can be errors. >>> I fail to see why the fact that the person has not been added to the >>> syndicate at the time of the upload should constitute a problem in any >>> >>> >> way. >> >> >>> Regards >>> >>> Brian Smart >>> >>> -----Original Message----- >>> From: freebmd-syndicates-bounces@rootsweb.com >>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>> Sent: 28 July 2010 17:08 >>> To: freebmd-syndicates@rootsweb.com >>> Subject: Non-syndicate transcriptions >>> >>> The error that caused transcriptions to erroneous get reported as _not_ >>> being done within a user's syndicate has now been corrected. If users >>> get the warning >>> >>> /You do not appear to be a member of a syndicate transcribing this >>> quarter. Please check you have the correct Year, Quarter and Event >>> or contact your syndicate coordinator./ >>> >>> the most likely causes are: >>> >>> * they have not been added to the syndicate they are transcribing for >>> * they have transcribed the wrong quarter >>> * they have specified the wrong year or quarter or event in the file >>> >>> Please note that files identified by this warning will not be allocated >>> to any syndicate and therefore coordinators will not be able to use >>> coordinator facilities (such as UploadReport for a particular syndicate >>> or downloading the file) for such a file. If the issue is that the >>> transcriber has not been added to the syndicate, it should be possible >>> to correct this by the transcriber uploading the file again (once the >>> transcriber has been added to the syndicate). You can use >>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a >>> file has been transcribed for. >>> >>> Because of feedback received this will remain a warning rather than >>> being upgraded to an error. >>> >>> Barrie >>> >>> >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>> >>> ------------------------------- >>> To unsubscribe from the list, please send an email to >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>> >>> >> without >> >> >>> the quotes in the subject and the body of the message >>> >>> >>> >>> >>> >>> >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >> >> ------------------------------- >> To unsubscribe from the list, please send an email to >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >> > without > >> the quotes in the subject and the body of the message >> >> >> >> >> > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Hello Barrie, I will prepare a list of the ones I know and send them to qa-coord@freebmd.org.uk Regards Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie Sent: 02 August 2010 08:25 To: freebmd-syndicates@rootsweb.com Subject: Re: RE: Duplicated scan pages Brian, Such gaps should be picked up when the SuperChunksReport <http://www.freebmd.org.uk/QualityAssuranceProcesses.html#superchunk> is reviewed but it would be helpful to report gaps to qa-coord@freebmd.org.uk as they are found so they can be inserted immediately. I will create a task to include this in the TKB. Barrie On 19:59, Brian Smart wrote: > Hello Barrie, > I have had many examples over the years where a scan has been duplicated. If > I have been satisfied that a scan is not missing as a result of the > duplication, I have always ignored the duplicate. This has never been raised > as an issue but statement that the gap will be handled...... seems to > suggest that something should have been done about it. > Regards > > Brian Smart > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 01 August 2010 08:47 > To: freebmd-syndicates@rootsweb.com > Subject: Re: Duplicated scan pages > > Jeff has answered the question but also the error that caused the the > "phantom" files to be rejected has been corrected. > > The gap will be handled by instructing the system that page 1233 follows > page 1228. > > Barrie > > On 19:59, Richard Oliver wrote: > >> <div class="moz-text-flowed" style="font-family: -moz-fixed">A >> volunteer in my Syndicate, SubmitterID hinkley, is transcribing the >> 'O' surnames from 1839 June Deaths, and reports that some of the scans >> are duplicates of some of the others. And indeed, I see from the >> list of scans that the contents of four of them - 1839D2-C-P-1225 (and >> the three pages following) are then repeated in the next four scans in >> the list, that is, 1839D2-C-P-1229 (to 1232 inclusive). >> >> I couldn't find a clear and unambiguous instruction on how to handle >> this situation - obviously, it would be silly to transcribe each page >> twice, but equally, wouldn't it be a problem to leave four files out >> of the numerical sequence, starting (say) File 1839D2O1225 with >> +PAGE,1225 but ending it with +PAGE,1233 ??? I advised him to raise >> four phantom files with the +PAGE items as usual but with no content >> between, or perhaps just a #COMMENT to explain the absence of >> records. But no, it appears the database has refused them, so please, >> what should my advice have been? >> >> Richard Oliver >> Madrid, Spain >> richol@arrakis.es >> >> >> >> </div> >> > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Brian, Such gaps should be picked up when the SuperChunksReport <http://www.freebmd.org.uk/QualityAssuranceProcesses.html#superchunk> is reviewed but it would be helpful to report gaps to qa-coord@freebmd.org.uk as they are found so they can be inserted immediately. I will create a task to include this in the TKB. Barrie On 19:59, Brian Smart wrote: > Hello Barrie, > I have had many examples over the years where a scan has been duplicated. If > I have been satisfied that a scan is not missing as a result of the > duplication, I have always ignored the duplicate. This has never been raised > as an issue but statement that the gap will be handled...... seems to > suggest that something should have been done about it. > Regards > > Brian Smart > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 01 August 2010 08:47 > To: freebmd-syndicates@rootsweb.com > Subject: Re: Duplicated scan pages > > Jeff has answered the question but also the error that caused the the > "phantom" files to be rejected has been corrected. > > The gap will be handled by instructing the system that page 1233 follows > page 1228. > > Barrie > > On 19:59, Richard Oliver wrote: > >> <div class="moz-text-flowed" style="font-family: -moz-fixed">A >> volunteer in my Syndicate, SubmitterID hinkley, is transcribing the >> 'O' surnames from 1839 June Deaths, and reports that some of the scans >> are duplicates of some of the others. And indeed, I see from the >> list of scans that the contents of four of them - 1839D2-C-P-1225 (and >> the three pages following) are then repeated in the next four scans in >> the list, that is, 1839D2-C-P-1229 (to 1232 inclusive). >> >> I couldn't find a clear and unambiguous instruction on how to handle >> this situation - obviously, it would be silly to transcribe each page >> twice, but equally, wouldn't it be a problem to leave four files out >> of the numerical sequence, starting (say) File 1839D2O1225 with >> +PAGE,1225 but ending it with +PAGE,1233 ??? I advised him to raise >> four phantom files with the +PAGE items as usual but with no content >> between, or perhaps just a #COMMENT to explain the absence of >> records. But no, it appears the database has refused them, so please, >> what should my advice have been? >> >> Richard Oliver >> Madrid, Spain >> richol@arrakis.es >> >> >> >> </div> >> > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner--

Hello Barrie, All file headers include an email address that can be checked to find the relevant syndicate. From this you can send an email to the associated coordinator advising the problem. All this can be automated so only the relevant coordinator has to take action. This overcomes all of your concerns. Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie Sent: 01 August 2010 00:36 To: freebmd-syndicates@rootsweb.com Subject: Re: RE: RE: RE: Non-syndicate transcriptions Brian, You seem to be under the misapprehension that there are several checks; you said: The problem exists because the checks that are performed includes one that checks if the uploaded file is one that has the transcriber signed up to a specific syndicate. If this part of the check was removed there would be no problem. In fact there is only _one_ check which is that the transcriber is a member of a syndicate transcribing the quarter. Failing this single check can be caused by: * transcribers not having been added to the syndicate they are transcribing for o because the coordinator has forgotten to add them o because they are not added until they have done their first transcription * transcribers transcribing the wrong quarter * transcribers specifying the wrong year or quarter or event in the file A short while ago I did a check on syndicate membership and found hundreds of instances of transcriptions that erroneously had no syndicate because the coordinator had forgotten to add the transcriber to their syndicate (you had one such transcriber who I notified you about). Such transcriptions would be incorrectly handled in the instances I gave in my previous posting, affecting _all_ coordinators and the system. It took a good deal of work to sort out (indeed it is still ongoing) and it is important that we do what we can to avoid getting into the same situation again by preventing the error at source. You complain that this check results in more work for you, but all you have to do is instruct your new transcribers to ignore the warning on their first upload. Barrie On 19:59, Brian Smart wrote: > Hello Barrie, > Re: > "The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting." > > The problem exists because the checks that are performed includes one that > checks if the uploaded file is one that has the transcriber signed up to a > specific syndicate. If this part of the check was removed there would be no > problem. > > > Re: > "* The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with" > > I seem to remember that the suspect files report used to indicate both > syndicates before this latest change. What is the problem with that? > > Re: > "* Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > > While this is true, the only coordinators affected by this are those like me > who do not add the person to the syndicate until they have uploaded a file. > I am quite happy with that situation. > > > Re: > "* The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate." > > > True but again it is only coordinators like me that this affects, thus this > is not a valid reason to change the system. > > > Re: > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > This is a minor short term problem and not a reason to cause those > transcribers like me who do not want the system changed. > > > Re: > > "So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable." > > > Again the coordinators affected are those like me and I am happy to accept > the situation. For me the result is less work not more. > > > Please remove this part of the checking process. > > Brian Smart > > > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 29 July 2010 17:48 > To: freebmd-syndicates@rootsweb.com > Subject: Re: RE: RE: Non-syndicate transcriptions > > Brian, > > The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting. > > When a file is uploaded the system makes a decision about what syndicate > it has been transcribed for and that syndicate (or syndicates if it is > ambiguous) is recorded with the file. The information about the > syndicate is used in (at least) the following ways: > > * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with > * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > * The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable. > > Regards > > Barrie > > On 19:59, Brian Smart wrote: > >> Hello Barrie, >> Surely the checking system needs to be changed then the problem would not >> exist. >> Regards >> >> Brian Smart >> >> >> -----Original Message----- >> From: freebmd-syndicates-bounces@rootsweb.com >> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >> Sent: 29 July 2010 00:15 >> To: freebmd-syndicates@rootsweb.com >> Subject: Re: RE: Non-syndicate transcriptions >> >> Brian, >> >> The clause you mention is not part of the warning; it was part of my >> explanation of the possible causes for the warning. >> >> The system cannot normally differentiate between these these three >> causes for the warning, it just knows that the file has not been marked >> as transcribed for a syndicate. >> >> Barrie >> >> On 19:59, Brian Smart wrote: >> >> >>> Hello Barrie, >>> Why not remove the cause: "* they have not been added to the syndicate >>> >>> >> they >> >> >>> are transcribing for" from this Warning/error and then the other two >>> possible causes can be errors. >>> I fail to see why the fact that the person has not been added to the >>> syndicate at the time of the upload should constitute a problem in any >>> >>> >> way. >> >> >>> Regards >>> >>> Brian Smart >>> >>> -----Original Message----- >>> From: freebmd-syndicates-bounces@rootsweb.com >>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>> Sent: 28 July 2010 17:08 >>> To: freebmd-syndicates@rootsweb.com >>> Subject: Non-syndicate transcriptions >>> >>> The error that caused transcriptions to erroneous get reported as _not_ >>> being done within a user's syndicate has now been corrected. If users >>> get the warning >>> >>> /You do not appear to be a member of a syndicate transcribing this >>> quarter. Please check you have the correct Year, Quarter and Event >>> or contact your syndicate coordinator./ >>> >>> the most likely causes are: >>> >>> * they have not been added to the syndicate they are transcribing for >>> * they have transcribed the wrong quarter >>> * they have specified the wrong year or quarter or event in the file >>> >>> Please note that files identified by this warning will not be allocated >>> to any syndicate and therefore coordinators will not be able to use >>> coordinator facilities (such as UploadReport for a particular syndicate >>> or downloading the file) for such a file. If the issue is that the >>> transcriber has not been added to the syndicate, it should be possible >>> to correct this by the transcriber uploading the file again (once the >>> transcriber has been added to the syndicate). You can use >>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a >>> file has been transcribed for. >>> >>> Because of feedback received this will remain a warning rather than >>> being upgraded to an error. >>> >>> Barrie >>> >>> >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>> >>> ------------------------------- >>> To unsubscribe from the list, please send an email to >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>> >>> >> without >> >> >>> the quotes in the subject and the body of the message >>> >>> >>> >>> >>> >>> >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >> >> ------------------------------- >> To unsubscribe from the list, please send an email to >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >> > without > >> the quotes in the subject and the body of the message >> >> >> >> >> > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Hello Barrie, I have had many examples over the years where a scan has been duplicated. If I have been satisfied that a scan is not missing as a result of the duplication, I have always ignored the duplicate. This has never been raised as an issue but statement that the gap will be handled...... seems to suggest that something should have been done about it. Regards Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie Sent: 01 August 2010 08:47 To: freebmd-syndicates@rootsweb.com Subject: Re: Duplicated scan pages Jeff has answered the question but also the error that caused the the "phantom" files to be rejected has been corrected. The gap will be handled by instructing the system that page 1233 follows page 1228. Barrie On 19:59, Richard Oliver wrote: > <div class="moz-text-flowed" style="font-family: -moz-fixed">A > volunteer in my Syndicate, SubmitterID hinkley, is transcribing the > 'O' surnames from 1839 June Deaths, and reports that some of the scans > are duplicates of some of the others. And indeed, I see from the > list of scans that the contents of four of them - 1839D2-C-P-1225 (and > the three pages following) are then repeated in the next four scans in > the list, that is, 1839D2-C-P-1229 (to 1232 inclusive). > > I couldn't find a clear and unambiguous instruction on how to handle > this situation - obviously, it would be silly to transcribe each page > twice, but equally, wouldn't it be a problem to leave four files out > of the numerical sequence, starting (say) File 1839D2O1225 with > +PAGE,1225 but ending it with +PAGE,1233 ??? I advised him to raise > four phantom files with the +PAGE items as usual but with no content > between, or perhaps just a #COMMENT to explain the absence of > records. But no, it appears the database has refused them, so please, > what should my advice have been? > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > > > </div> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Hello Barrie, I have had many examples over the years where a scan has been duplicated. If I have been satisfied that a scan is not missing as a result of the duplication, I have always ignored the duplicate. This has never been raised as an issue but statement that the gap will be handled...... seems to suggest that something should have been done about it. Regards Brian Smart -----Original Message----- From: freebmd-syndicates-bounces@rootsweb.com [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie Sent: 01 August 2010 08:47 To: freebmd-syndicates@rootsweb.com Subject: Re: Duplicated scan pages Jeff has answered the question but also the error that caused the the "phantom" files to be rejected has been corrected. The gap will be handled by instructing the system that page 1233 follows page 1228. Barrie On 19:59, Richard Oliver wrote: > <div class="moz-text-flowed" style="font-family: -moz-fixed">A > volunteer in my Syndicate, SubmitterID hinkley, is transcribing the > 'O' surnames from 1839 June Deaths, and reports that some of the scans > are duplicates of some of the others. And indeed, I see from the > list of scans that the contents of four of them - 1839D2-C-P-1225 (and > the three pages following) are then repeated in the next four scans in > the list, that is, 1839D2-C-P-1229 (to 1232 inclusive). > > I couldn't find a clear and unambiguous instruction on how to handle > this situation - obviously, it would be silly to transcribe each page > twice, but equally, wouldn't it be a problem to leave four files out > of the numerical sequence, starting (say) File 1839D2O1225 with > +PAGE,1225 but ending it with +PAGE,1233 ??? I advised him to raise > four phantom files with the +PAGE items as usual but with no content > between, or perhaps just a #COMMENT to explain the absence of > records. But no, it appears the database has refused them, so please, > what should my advice have been? > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > > > </div> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- ------------------------------- To unsubscribe from the list, please send an email to FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Jeff has answered the question but also the error that caused the the "phantom" files to be rejected has been corrected. The gap will be handled by instructing the system that page 1233 follows page 1228. Barrie On 19:59, Richard Oliver wrote: > <div class="moz-text-flowed" style="font-family: -moz-fixed">A > volunteer in my Syndicate, SubmitterID hinkley, is transcribing the > 'O' surnames from 1839 June Deaths, and reports that some of the scans > are duplicates of some of the others. And indeed, I see from the > list of scans that the contents of four of them - 1839D2-C-P-1225 (and > the three pages following) are then repeated in the next four scans in > the list, that is, 1839D2-C-P-1229 (to 1232 inclusive). > > I couldn't find a clear and unambiguous instruction on how to handle > this situation - obviously, it would be silly to transcribe each page > twice, but equally, wouldn't it be a problem to leave four files out > of the numerical sequence, starting (say) File 1839D2O1225 with > +PAGE,1225 but ending it with +PAGE,1233 ??? I advised him to raise > four phantom files with the +PAGE items as usual but with no content > between, or perhaps just a #COMMENT to explain the absence of > records. But no, it appears the database has refused them, so please, > what should my advice have been? > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > > > </div> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner--

Brian, You seem to be under the misapprehension that there are several checks; you said: The problem exists because the checks that are performed includes one that checks if the uploaded file is one that has the transcriber signed up to a specific syndicate. If this part of the check was removed there would be no problem. In fact there is only _one_ check which is that the transcriber is a member of a syndicate transcribing the quarter. Failing this single check can be caused by: * transcribers not having been added to the syndicate they are transcribing for o because the coordinator has forgotten to add them o because they are not added until they have done their first transcription * transcribers transcribing the wrong quarter * transcribers specifying the wrong year or quarter or event in the file A short while ago I did a check on syndicate membership and found hundreds of instances of transcriptions that erroneously had no syndicate because the coordinator had forgotten to add the transcriber to their syndicate (you had one such transcriber who I notified you about). Such transcriptions would be incorrectly handled in the instances I gave in my previous posting, affecting _all_ coordinators and the system. It took a good deal of work to sort out (indeed it is still ongoing) and it is important that we do what we can to avoid getting into the same situation again by preventing the error at source. You complain that this check results in more work for you, but all you have to do is instruct your new transcribers to ignore the warning on their first upload. Barrie On 19:59, Brian Smart wrote: > Hello Barrie, > Re: > "The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting." > > The problem exists because the checks that are performed includes one that > checks if the uploaded file is one that has the transcriber signed up to a > specific syndicate. If this part of the check was removed there would be no > problem. > > > Re: > "* The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with" > > I seem to remember that the suspect files report used to indicate both > syndicates before this latest change. What is the problem with that? > > Re: > "* Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > > While this is true, the only coordinators affected by this are those like me > who do not add the person to the syndicate until they have uploaded a file. > I am quite happy with that situation. > > > Re: > "* The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate." > > > True but again it is only coordinators like me that this affects, thus this > is not a valid reason to change the system. > > > Re: > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > This is a minor short term problem and not a reason to cause those > transcribers like me who do not want the system changed. > > > Re: > > "So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable." > > > Again the coordinators affected are those like me and I am happy to accept > the situation. For me the result is less work not more. > > > Please remove this part of the checking process. > > Brian Smart > > > > > -----Original Message----- > From: freebmd-syndicates-bounces@rootsweb.com > [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie > Sent: 29 July 2010 17:48 > To: freebmd-syndicates@rootsweb.com > Subject: Re: RE: RE: Non-syndicate transcriptions > > Brian, > > The check merely indicates the problem exists; changing the check won't > make the problem go away. The issue is, I think, whether a non-syndicate > transcription is a problem so let me expand on what I said in my > original posting. > > When a file is uploaded the system makes a decision about what syndicate > it has been transcribed for and that syndicate (or syndicates if it is > ambiguous) is recorded with the file. The information about the > syndicate is used in (at least) the following ways: > > * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> > list shows the syndicate of the file; this allows coordinators to > see which files they need to be concerned with > * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has > the option for the results to be dependent on the syndicate of the > file (e.g. list only files transcribed for a particular syndicate) > * The coordinator version of Show File > <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow > coordinators to download the file if it has been transcribed for > their syndicate > * When the database is created the syndicate of the file is used to > determine of there is duplication within a syndicate; an entry is > not considered to be double keyed if both transcriptions are > within a syndicate > > So it is quite important that the syndicate a file is transcribed for is > correct. If it isn't coordinators will be put to extra work and so I > don't understand why not having a syndicate could be considered acceptable. > > Regards > > Barrie > > On 19:59, Brian Smart wrote: > >> Hello Barrie, >> Surely the checking system needs to be changed then the problem would not >> exist. >> Regards >> >> Brian Smart >> >> >> -----Original Message----- >> From: freebmd-syndicates-bounces@rootsweb.com >> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >> Sent: 29 July 2010 00:15 >> To: freebmd-syndicates@rootsweb.com >> Subject: Re: RE: Non-syndicate transcriptions >> >> Brian, >> >> The clause you mention is not part of the warning; it was part of my >> explanation of the possible causes for the warning. >> >> The system cannot normally differentiate between these these three >> causes for the warning, it just knows that the file has not been marked >> as transcribed for a syndicate. >> >> Barrie >> >> On 19:59, Brian Smart wrote: >> >> >>> Hello Barrie, >>> Why not remove the cause: "* they have not been added to the syndicate >>> >>> >> they >> >> >>> are transcribing for" from this Warning/error and then the other two >>> possible causes can be errors. >>> I fail to see why the fact that the person has not been added to the >>> syndicate at the time of the upload should constitute a problem in any >>> >>> >> way. >> >> >>> Regards >>> >>> Brian Smart >>> >>> -----Original Message----- >>> From: freebmd-syndicates-bounces@rootsweb.com >>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>> Sent: 28 July 2010 17:08 >>> To: freebmd-syndicates@rootsweb.com >>> Subject: Non-syndicate transcriptions >>> >>> The error that caused transcriptions to erroneous get reported as _not_ >>> being done within a user's syndicate has now been corrected. If users >>> get the warning >>> >>> /You do not appear to be a member of a syndicate transcribing this >>> quarter. Please check you have the correct Year, Quarter and Event >>> or contact your syndicate coordinator./ >>> >>> the most likely causes are: >>> >>> * they have not been added to the syndicate they are transcribing for >>> * they have transcribed the wrong quarter >>> * they have specified the wrong year or quarter or event in the file >>> >>> Please note that files identified by this warning will not be allocated >>> to any syndicate and therefore coordinators will not be able to use >>> coordinator facilities (such as UploadReport for a particular syndicate >>> or downloading the file) for such a file. If the issue is that the >>> transcriber has not been added to the syndicate, it should be possible >>> to correct this by the transcriber uploading the file again (once the >>> transcriber has been added to the syndicate). You can use >>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a >>> file has been transcribed for. >>> >>> Because of feedback received this will remain a warning rather than >>> being upgraded to an error. >>> >>> Barrie >>> >>> >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>> >>> ------------------------------- >>> To unsubscribe from the list, please send an email to >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>> >>> >> without >> >> >>> the quotes in the subject and the body of the message >>> >>> >>> >>> >>> >>> >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >> >> ------------------------------- >> To unsubscribe from the list, please send an email to >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >> > without > >> the quotes in the subject and the body of the message >> >> >> >> >> > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner--

http://www.freebmd.org.uk/vol_faq.html#6aa and http://www.freebmd.org.uk/vol_faq.html#10b seem to be the nearest advice. Just ignore the second run of scans seems to be what comes from TKB 10(a) Jeff ----- Original Message ----- From: "Richard Oliver" <richol@arrakis.es> To: <freebmd-syndicates@rootsweb.com> Sent: Saturday, July 31, 2010 9:33 PM Subject: Duplicated scan pages >A volunteer in my Syndicate, SubmitterID hinkley, is transcribing the 'O' > surnames from 1839 June Deaths, and reports that some of the scans are > duplicates of some of the others. And indeed, I see from the list of > scans > that the contents of four of them - 1839D2-C-P-1225 (and the three pages > following) are then repeated in the next four scans in the list, that is, > 1839D2-C-P-1229 (to 1232 inclusive). > > I couldn't find a clear and unambiguous instruction on how to handle this > situation - obviously, it would be silly to transcribe each page twice, > but > equally, wouldn't it be a problem to leave four files out of the numerical > sequence, starting (say) File 1839D2O1225 with +PAGE,1225 but ending it > with > +PAGE,1233 ??? I advised him to raise four phantom files with the +PAGE > items as usual but with no content between, or perhaps just a #COMMENT to > explain the absence of records. But no, it appears the database has > refused > them, so please, what should my advice have been? > > Richard Oliver > Madrid, Spain > richol@arrakis.es > > > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without the quotes in the subject and the body of the message >

A volunteer in my Syndicate, SubmitterID hinkley, is transcribing the 'O' surnames from 1839 June Deaths, and reports that some of the scans are duplicates of some of the others. And indeed, I see from the list of scans that the contents of four of them - 1839D2-C-P-1225 (and the three pages following) are then repeated in the next four scans in the list, that is, 1839D2-C-P-1229 (to 1232 inclusive). I couldn't find a clear and unambiguous instruction on how to handle this situation - obviously, it would be silly to transcribe each page twice, but equally, wouldn't it be a problem to leave four files out of the numerical sequence, starting (say) File 1839D2O1225 with +PAGE,1225 but ending it with +PAGE,1233 ??? I advised him to raise four phantom files with the +PAGE items as usual but with no content between, or perhaps just a #COMMENT to explain the absence of records. But no, it appears the database has refused them, so please, what should my advice have been? Richard Oliver Madrid, Spain richol@arrakis.es

Thanks Barrie I suspected that would be the case, but it is useful to be sure. Regards Jeff ----- Original Message ----- From: "Barrie" <freebmd@myarcher.net> To: <freebmd-syndicates@rootsweb.com> Sent: Friday, July 30, 2010 2:09 PM Subject: Re: Re: RE: RE: Non-syndicate transcriptions > Jeff, > > The convention to put the syndicate name (or country name) in the file > is one initiated with SpeedBMD and adopted by WinBMD, MacBMD and linbmd. > The information is put in a comment line after the +INFO line. However, > this is not part of the definition of the input format (although it has > been updated to mention it) and does not exist in word > processor/spreadsheet files. > > Since the information is a comment the system should, in principle, > ignore it. However, pragmatism to the fore, we do actually use the > information but only subsidiary to the formal information. Hence, the > primary determination of the syndicate of a file is the syndicate(s) the > user is a member of and which is (are) transcribing the quarter. The > syndicate name in the file is then used in two circumstances: > > * If there is more than one possible syndicate from the above process > * If there is no syndicate from the above process and the syndicate > in the file is 'Individual' > > Another issue is that the name of the syndicate entered is not checked > on upload (because it is a comment) and there are a number of > variations, for example the recognised aliases for your syndicate > (correct name Jeff Coleman Syndicate) are: > Jeff Coleman > Jeff Colemen > jeff colman > jeff.coleman > jeffcoleman > Jeffr Coleman > > Given the informality of the information and the variations it would be > unwise to use it as a primary source. > >>From the way in which the information is used I don't think it is worth > trying to get transcribers to complete the input field differently, > especially since the only effective way of doing this would be to change > the transcription software. > > Barrie > > On 19:59, Jeff Coleman wrote: >> <div class="moz-text-flowed" style="font-family: -moz-fixed">Barrie >> >> In the WinBMD header, the relevant field is labelled 'Syndicate (or >> country)' so some transcribers will put England, Australia etc. in >> there, rather that a syndicate name. >> >> In such cases presumably the system has to check whether the quarter >> the file belongs to is being transcribed by a syndicate on whose list >> the transcriber appears. >> >> Is there any need to give any different advice to transcribers about >> how to fill in that field? >> >> Jeff >> >> >> ----- Original Message ----- From: "Barrie" <freebmd@myarcher.net> >> To: <freebmd-syndicates@rootsweb.com> >> Sent: Thursday, July 29, 2010 5:47 PM >> Subject: Re: RE: RE: Non-syndicate transcriptions >> >> >>> Brian, >>> >>> The check merely indicates the problem exists; changing the check won't >>> make the problem go away. The issue is, I think, whether a non-syndicate >>> transcription is a problem so let me expand on what I said in my >>> original posting. >>> >>> When a file is uploaded the system makes a decision about what syndicate >>> it has been transcribed for and that syndicate (or syndicates if it is >>> ambiguous) is recorded with the file. The information about the >>> syndicate is used in (at least) the following ways: >>> >>> * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> >>> list shows the syndicate of the file; this allows coordinators to >>> see which files they need to be concerned with >>> * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has >>> the option for the results to be dependent on the syndicate of the >>> file (e.g. list only files transcribed for a particular syndicate) >>> * The coordinator version of Show File >>> <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow >>> coordinators to download the file if it has been transcribed for >>> their syndicate >>> * When the database is created the syndicate of the file is used to >>> determine of there is duplication within a syndicate; an entry is >>> not considered to be double keyed if both transcriptions are >>> within a syndicate >>> >>> So it is quite important that the syndicate a file is transcribed for is >>> correct. If it isn't coordinators will be put to extra work and so I >>> don't understand why not having a syndicate could be considered >>> acceptable. >>> >>> Regards >>> >>> Barrie >>> >>> On 19:59, Brian Smart wrote: >>>> Hello Barrie, >>>> Surely the checking system needs to be changed then the problem >>>> would not >>>> exist. >>>> Regards >>>> >>>> Brian Smart >>>> >>>> >>>> -----Original Message----- >>>> From: freebmd-syndicates-bounces@rootsweb.com >>>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>>> Sent: 29 July 2010 00:15 >>>> To: freebmd-syndicates@rootsweb.com >>>> Subject: Re: RE: Non-syndicate transcriptions >>>> >>>> Brian, >>>> >>>> The clause you mention is not part of the warning; it was part of my >>>> explanation of the possible causes for the warning. >>>> >>>> The system cannot normally differentiate between these these three >>>> causes for the warning, it just knows that the file has not been marked >>>> as transcribed for a syndicate. >>>> >>>> Barrie >>>> >>>> On 19:59, Brian Smart wrote: >>>> >>>>> Hello Barrie, >>>>> Why not remove the cause: "* they have not been added to the syndicate >>>>> >>>> they >>>> >>>>> are transcribing for" from this Warning/error and then the other two >>>>> possible causes can be errors. >>>>> I fail to see why the fact that the person has not been added to the >>>>> syndicate at the time of the upload should constitute a problem in any >>>>> >>>> way. >>>> >>>>> Regards >>>>> >>>>> Brian Smart >>>>> >>>>> -----Original Message----- >>>>> From: freebmd-syndicates-bounces@rootsweb.com >>>>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>>>> Sent: 28 July 2010 17:08 >>>>> To: freebmd-syndicates@rootsweb.com >>>>> Subject: Non-syndicate transcriptions >>>>> >>>>> The error that caused transcriptions to erroneous get reported as >>>>> _not_ >>>>> being done within a user's syndicate has now been corrected. If users >>>>> get the warning >>>>> >>>>> /You do not appear to be a member of a syndicate transcribing this >>>>> quarter. Please check you have the correct Year, Quarter and Event >>>>> or contact your syndicate coordinator./ >>>>> >>>>> the most likely causes are: >>>>> >>>>> * they have not been added to the syndicate they are >>>>> transcribing for >>>>> * they have transcribed the wrong quarter >>>>> * they have specified the wrong year or quarter or event in the >>>>> file >>>>> >>>>> Please note that files identified by this warning will not be >>>>> allocated >>>>> to any syndicate and therefore coordinators will not be able to use >>>>> coordinator facilities (such as UploadReport for a particular >>>>> syndicate >>>>> or downloading the file) for such a file. If the issue is that the >>>>> transcriber has not been added to the syndicate, it should be possible >>>>> to correct this by the transcriber uploading the file again (once the >>>>> transcriber has been added to the syndicate). You can use >>>>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a >>>>> file has been transcribed for. >>>>> >>>>> Because of feedback received this will remain a warning rather than >>>>> being upgraded to an error. >>>>> >>>>> Barrie >>>>> >>>>> >>>>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>>>> >>>>> ------------------------------- >>>>> To unsubscribe from the list, please send an email to >>>>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>>>> >>>> without >>>> >>>>> the quotes in the subject and the body of the message >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>>> >>>> ------------------------------- >>>> To unsubscribe from the list, please send an email to >>>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>>> without >>>> the quotes in the subject and the body of the message >>>> >>>> >>>> >>>> >>> >>> >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>> >>> ------------------------------- >>> To unsubscribe from the list, please send an email to >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>> without the quotes in the subject and the body of the message >>> >> >> >> >> </div> > > > --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- > > ------------------------------- > To unsubscribe from the list, please send an email to > FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' > without the quotes in the subject and the body of the message >

Jeff, The convention to put the syndicate name (or country name) in the file is one initiated with SpeedBMD and adopted by WinBMD, MacBMD and linbmd. The information is put in a comment line after the +INFO line. However, this is not part of the definition of the input format (although it has been updated to mention it) and does not exist in word processor/spreadsheet files. Since the information is a comment the system should, in principle, ignore it. However, pragmatism to the fore, we do actually use the information but only subsidiary to the formal information. Hence, the primary determination of the syndicate of a file is the syndicate(s) the user is a member of and which is (are) transcribing the quarter. The syndicate name in the file is then used in two circumstances: * If there is more than one possible syndicate from the above process * If there is no syndicate from the above process and the syndicate in the file is 'Individual' Another issue is that the name of the syndicate entered is not checked on upload (because it is a comment) and there are a number of variations, for example the recognised aliases for your syndicate (correct name Jeff Coleman Syndicate) are: Jeff Coleman Jeff Colemen jeff colman jeff.coleman jeffcoleman Jeffr Coleman Given the informality of the information and the variations it would be unwise to use it as a primary source. >From the way in which the information is used I don't think it is worth trying to get transcribers to complete the input field differently, especially since the only effective way of doing this would be to change the transcription software. Barrie On 19:59, Jeff Coleman wrote: > <div class="moz-text-flowed" style="font-family: -moz-fixed">Barrie > > In the WinBMD header, the relevant field is labelled 'Syndicate (or > country)' so some transcribers will put England, Australia etc. in > there, rather that a syndicate name. > > In such cases presumably the system has to check whether the quarter > the file belongs to is being transcribed by a syndicate on whose list > the transcriber appears. > > Is there any need to give any different advice to transcribers about > how to fill in that field? > > Jeff > > > ----- Original Message ----- From: "Barrie" <freebmd@myarcher.net> > To: <freebmd-syndicates@rootsweb.com> > Sent: Thursday, July 29, 2010 5:47 PM > Subject: Re: RE: RE: Non-syndicate transcriptions > > >> Brian, >> >> The check merely indicates the problem exists; changing the check won't >> make the problem go away. The issue is, I think, whether a non-syndicate >> transcription is a problem so let me expand on what I said in my >> original posting. >> >> When a file is uploaded the system makes a decision about what syndicate >> it has been transcribed for and that syndicate (or syndicates if it is >> ambiguous) is recorded with the file. The information about the >> syndicate is used in (at least) the following ways: >> >> * The Suspect Files <http://www.freebmd.org.uk/SuspectFiles.html> >> list shows the syndicate of the file; this allows coordinators to >> see which files they need to be concerned with >> * Upload Report <http://www.freebmd.org.uk/cgi/upload-report.pl> has >> the option for the results to be dependent on the syndicate of the >> file (e.g. list only files transcribed for a particular syndicate) >> * The coordinator version of Show File >> <http://www.freebmd.org.uk/cgi/coord-show-file.pl> will allow >> coordinators to download the file if it has been transcribed for >> their syndicate >> * When the database is created the syndicate of the file is used to >> determine of there is duplication within a syndicate; an entry is >> not considered to be double keyed if both transcriptions are >> within a syndicate >> >> So it is quite important that the syndicate a file is transcribed for is >> correct. If it isn't coordinators will be put to extra work and so I >> don't understand why not having a syndicate could be considered >> acceptable. >> >> Regards >> >> Barrie >> >> On 19:59, Brian Smart wrote: >>> Hello Barrie, >>> Surely the checking system needs to be changed then the problem >>> would not >>> exist. >>> Regards >>> >>> Brian Smart >>> >>> >>> -----Original Message----- >>> From: freebmd-syndicates-bounces@rootsweb.com >>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>> Sent: 29 July 2010 00:15 >>> To: freebmd-syndicates@rootsweb.com >>> Subject: Re: RE: Non-syndicate transcriptions >>> >>> Brian, >>> >>> The clause you mention is not part of the warning; it was part of my >>> explanation of the possible causes for the warning. >>> >>> The system cannot normally differentiate between these these three >>> causes for the warning, it just knows that the file has not been marked >>> as transcribed for a syndicate. >>> >>> Barrie >>> >>> On 19:59, Brian Smart wrote: >>> >>>> Hello Barrie, >>>> Why not remove the cause: "* they have not been added to the syndicate >>>> >>> they >>> >>>> are transcribing for" from this Warning/error and then the other two >>>> possible causes can be errors. >>>> I fail to see why the fact that the person has not been added to the >>>> syndicate at the time of the upload should constitute a problem in any >>>> >>> way. >>> >>>> Regards >>>> >>>> Brian Smart >>>> >>>> -----Original Message----- >>>> From: freebmd-syndicates-bounces@rootsweb.com >>>> [mailto:freebmd-syndicates-bounces@rootsweb.com] On Behalf Of Barrie >>>> Sent: 28 July 2010 17:08 >>>> To: freebmd-syndicates@rootsweb.com >>>> Subject: Non-syndicate transcriptions >>>> >>>> The error that caused transcriptions to erroneous get reported as >>>> _not_ >>>> being done within a user's syndicate has now been corrected. If users >>>> get the warning >>>> >>>> /You do not appear to be a member of a syndicate transcribing this >>>> quarter. Please check you have the correct Year, Quarter and Event >>>> or contact your syndicate coordinator./ >>>> >>>> the most likely causes are: >>>> >>>> * they have not been added to the syndicate they are >>>> transcribing for >>>> * they have transcribed the wrong quarter >>>> * they have specified the wrong year or quarter or event in the >>>> file >>>> >>>> Please note that files identified by this warning will not be >>>> allocated >>>> to any syndicate and therefore coordinators will not be able to use >>>> coordinator facilities (such as UploadReport for a particular >>>> syndicate >>>> or downloading the file) for such a file. If the issue is that the >>>> transcriber has not been added to the syndicate, it should be possible >>>> to correct this by the transcriber uploading the file again (once the >>>> transcriber has been added to the syndicate). You can use >>>> http://www.freebmd.org.uk/cgi/show-file.pl to check which syndicate a >>>> file has been transcribed for. >>>> >>>> Because of feedback received this will remain a warning rather than >>>> being upgraded to an error. >>>> >>>> Barrie >>>> >>>> >>>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>>> >>>> ------------------------------- >>>> To unsubscribe from the list, please send an email to >>>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>>> >>> without >>> >>>> the quotes in the subject and the body of the message >>>> >>>> >>>> >>>> >>>> >>> >>> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >>> >>> ------------------------------- >>> To unsubscribe from the list, please send an email to >>> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >>> without >>> the quotes in the subject and the body of the message >>> >>> >>> >>> >> >> >> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner-- >> >> ------------------------------- >> To unsubscribe from the list, please send an email to >> FREEBMD-SYNDICATES-request@rootsweb.com with the word 'unsubscribe' >> without the quotes in the subject and the body of the message >> > > > > </div> --Certified Virus Free by 4SecureMail.com ICSA-Certified Scanner--