diff --git a/handbook/computing/todo.html b/handbook/computing/todo.html
index b05c658ee..b0b115795 100644
--- a/handbook/computing/todo.html
+++ b/handbook/computing/todo.html
@@ -43,7 +43,13 @@ but now we are just going to use standard HTML5 tags.
 Click here if no todo list appears here (because 'frames' have been disabled).</div></a>
 <hr>
 
-
+<h3>Other coding To Do things</h3>
+<p>See also these long-running issues which have their own 'to do' implications:
+<ol>
+<li><a href="/handbook/troggle/trogdesign.html">What Troggle Does Badly - Design Decisions</a>
+<li><a href="/handbook/troggle/menudesign.html">New Menu System</a>
+<li><a href="/handbook/troggle/trog2030.html">Troggle in 2025-2030</a>
+</ol>
 <h3>Process Documentation</h3>
     <details><summary><!--2020-03-26 psargent-->Wallets and new-cave</summary>
         <li><!--2020-03-26 psargent-->Explain how to link a new cave into the other caves in
diff --git a/handbook/troggle/trog2030.html b/handbook/troggle/trog2030.html
index 424895f6b..2495a306c 100644
--- a/handbook/troggle/trog2030.html
+++ b/handbook/troggle/trog2030.html
@@ -68,11 +68,43 @@ all the multi-user non-interference, not Django. So unless we want to roll our o
 <div style="color:blue">
 <p>We need to de-cruft troggle *first*: remove 'good ideas' which were never used, trim redundancies and generally reduce it in size significantly.
 <p>
-We should have a good look  at  making a list of functions that we will drop and some we replace by parsing cavern output and some we calculate during importing/reading svx files.
+We should have a good look  at  making a list of functions that we will drop and some we replace by parsing cavern output and some we calculate 
+during importing/reading svx files.
 
 <p>
-Documentation and a working list of on-going programming projects is the key to keeping troggle in a state where someone can pick it up and do a useful week's work, e.g. extracting the parsed logbooks to use shelve() storage throughout instead of SQL. The next time someone like Radost comes along during the next 5 years we want to be able to use them effectively.
+Documentation and a working list of on-going programming projects is the key to keeping troggle in a state where someone can pick it up and do a 
+useful week's work, e.g. extracting the parsed logbooks to use shelve() storage throughout instead of SQL. The next time someone like Radost comes 
+along during the next 5 years we want to be able to use them effectively.
 </div>
+
+<h3>Option Zero.1</h2>
+<div style="color:blue">
+<p>We should probably review and revise all the over-complex templates, originally written in 2006, which do serious amounts of database querying, 
+and linked object sub-querying, within the template code. This is a nightmare to maintain and debug, e.g. see 
+the note at the bottom of <a href="/personexpedition/Wookey/1999">Wookey 1999 trips</a>.
+
+<p>A possible goal would be to create all the data that will be displayed in a page as dictionaries - generated by obviously simple python, with 
+some Django query optimisations if necessary - which are then handed as 'context' to the Django page template (those files in <var>
+troggle/templates/xxx.html</var>), instead of using the Django-specific database object requests within the template sublanguage, e.g. 
+<code><pre>
+  {% if persondate.2 %}
+    &lt;td class="survexblock"&gt;&lt;a href="{% url "svx" persondate.2.survexfile.path %}"&gt;{{persondate.2.name}}&lt;/a&gt;&lt;/td&gt;
+        {%comment%}
+        &lt;td class="roles" style="padding-right: 3px; text-align:right"&gt;
+        {% for survexpersonrole in persondate.2.survexpersonrole_set.all %}
+          {{survexpersonrole.nrole}}
+        {% endfor %}
+        &lt;/td&gt;{%endcomment%}
+&lt;td style="text-align:right"&gt;
+    {{persondate.2.legslength|stringformat:".1f"}} m
+    &lt;/td&gt;
+  {% else %}
+    &lt;td colspan="3"&gt; &lt;/td&gt;
+  {% endif %}
+  </pre></code>
+
+</div>
+
 <h3>Things that could be a bit sticky 1 - multi-user safety</h3>
 <p>Multi-user synchronous use could be a bit tricky without a solid multi-user database sitting behind the python code. So removing all the SQL database use may not be what we want to do after all.
 <p>Under all conceivable circumstances we would continue to use WGSI or