From a53d7e27278737caa2a4e95486d389e9823f378b Mon Sep 17 00:00:00 2001
From: Expo on server <expo@expo.survex.com>
Date: Sat, 20 Jul 2024 10:34:53 +0100
Subject: [PATCH] remove the 2022 TICK procedure as it is too complicated -
 online edit of handbook/survey/qmentry.html

---
 handbook/survey/qmentry.html | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/handbook/survey/qmentry.html b/handbook/survey/qmentry.html
index aa0e80171..88013f2ab 100644
--- a/handbook/survey/qmentry.html
+++ b/handbook/survey/qmentry.html
@@ -138,29 +138,28 @@ real content replaces template text):</p>
 ;[ QM2    B    surveyname.5    -    description of QM ]
 
 ;TICKed off QMs
-; in the past, if another survey existed, the resolution-station
-; field was filled in, e.g.
+; if another later survey exists, the resolution-station
+; field is filled in, e.g.
 ;[ QM2    B    surveyname.5   anothersurvey.7    description of QM and description of progress ]
 
-; or we can use the trial format
-;Serial number TICK  date resolution description
-;[QM2 TICK 2022-07-20 This is an example ticked QM]
+; or if there is no survey, but the QM is dead tehn repeat the original survey station:
+;[ QM2    B    surveyname.5   surveyname.5    description of QM resolution DATE and description of results ]
 </pre></code>
 
 
-<p>Since 2015 we have had no generally-agreed, well-documented or widely-practiced way of recording whether a QM has been ticked-off or not. 
+<p>In 2015 we had had no generally-agreed, well-documented or widely-practiced way of recording whether a QM has been ticked-off or not. 
 
-<p>In the past, this was done by 
+<p>We now do this by 
 <ol>
 <li>surveying into the passage beyond the QM, 
 <li>creating a new survex file for that survey, 
 and then 
 <li>editing the original survex file using the name of one of those new survey stations as the "resolution-station", replacing the "-" previously there. 
-</ol>This meant that a QM 
-could only be ticked-off if there was, in fact, surveyable passage beyond it, and if it was worth surveying, and if 
-someone did so.
+</ol>
 
-<p>In 2022 we had a proposal  to add an extra line to the original survex file, now that survex files can be edited 
+<p>If the new QM is explored but is not worth surveying (e.g. a snow-filled drop which in a later year is seen to be just a pile of snow), then edit the original survex file to repeat the same survey satstion as the "resolution station" and put a comment with the <em>date</em> this was done and a reference to the logbook entry or wallet.
+
+<!--<p>In 2022 we had a proposal  to add an extra line to the original survex file, now that survex files can be edited 
 easily on-line (and the version control happens invisibly and automatically):
 
 <code>
@@ -175,7 +174,7 @@ in <a href="/survexfile/caves-1623/258/flashhard2.svx">258/flashhard2.svx</a>. <
 The TICKed QM appears at the end of the report <a href="/cave/qms/1623-258">/cave/qms/1623-258</a> at the bottom of the page.</p>
 
 <p>The <var>date</var> field is sufficient to tie the tick-off event to one of a small number of logbook entries and survex files, which is where the actual exploration would be documented. If it was a rapid dead-end, or if later parties can't find it at all, then there should be just a logbook entry.
-
+-->
 
 <h3>Programming note</h3>
 <p>Better handling of historic QMs is a current, occasionally active, area of