expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-08 14:54:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge

Browse Source
This commit is contained in:
Wookey
2020-02-23 03:51:22 +00:00
parent 79518497b5 d1e301a464
commit ae48195d61
1001 changed files with 6170 additions and 4273 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
handbook/bankofexpo.html
View File

@@ -12,7 +12,7 @@
<p><em>Please be respectful of this website as you'll find you can edit transactions that others have listed. This is to allow people to collaboratively add their combined expenses with all the complications that cavers bring to anything. However, it could be abused. Please don't. The admins can see records of who changed what and when. </em>
<p>BoC was originally designed for <b>caving club/meet use</b>, but is flexible enough for expo use, where expenses are distributed by number of nights/car-passengers/beers. Being online helps accounting transparency, allows real-time review of creditors/debtors, and, if input permissions are devolved, reduces the burden on the treasurer. Once everything is entered and correctly allocated the accounts should be done without further work. It correctly handles multiple currencies and exchange rates changing over time.
<p>Please read how these expenses records are also kept manually on paper in the <a href="bierbook.html">Bier and Sesh books</a> in the potato hut.
<p>The 2018 Bank of Expo is hosted at <a href="http://expo.survex.com/boe">expo.survex.com/boe</a>.
<p>The current Bank of Expo is hosted at <a href="http://expo.survex.com/boe/">expo.survex.com/boe/</a> (and the previous year at <a href="http://expo.survex.com/boe-lastyear/">expo.survex.com/boe-lastyear/</a>.
<p>Bank of Expo (and the same software running as Bank of CUCC for ordinary caving trips) was written by Stuart Bennett in Cambridge. He says:
<p>
<em>"BoC is a multi-user auditable online share-based accounting system. The `share-based' part is probably its distinguishing feature: absolute amounts are split evenly across the slates of implicated users and/or ring-fenced cost-pools. Transactions are automatically double-entry, and as real-world transactions are made against a real bank account, the
@@ -20,10 +20,9 @@
<p>
The split mechanism transparently underlies everything, but for user-friendliness there are various handy web-forms provided which generate the split tables (`Transaction Groups'). These range from a simple person-to-person swap, to a customizable `Event' with costs for various items being automatically squirrelled away into pre-set cost-pools."</em>
<p>Now read the online documentation at <a href="https://github.com/malc0/BoC">https://github.com/malc0/BoC</a> which has a link to a demonstration system that you can play with (CUCC meets 2014-15).
<p>Now read the <a href="boc.pdf">the documentation</a> (PDF) (for the version running on the expo server).</p>
<p>
Here is the <a href="bocdoc.pdf">the original documentation</a> (PDF). It's a bit out of date: the instructions online largely replace Chapter 2.
<p>Source and docs for the upstream version are online at <a href="https://github.com/malc0/BoC">https://github.com/malc0/BoC</a> which has a link to a demonstration system that you can play with (CUCC meets 2014-15).</p>
<hr />

BIN
handbook/bocdoc.pdf → handbook/boc.pdf
View File

Binary file not shown.

59
handbook/computing/folkupdate.html Normal file
View File

@@ -0,0 +1,59 @@
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>CUCC Expedition Handbook: People Update</title>
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head>
<body>
<h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>The list of people on expo</h1>
<p>These are nerd-instructions. Find a nerd if you think this needs to be done.
<h3 id="import">The folk list</a></h3>
<p>This is part of the <a href="newyear.html">"new expo year"</a> preparations.
The folk.csv file is stored on the server under version control in the ::expoweb:: repository in
<code>expoweb/folk/folk.csv</code>
<p>Before expo starts the folk.csv file is updated.
<p>Edit folk/folk.csv, adding the new year to the end of the header line, a new column, with just a comma (blank cell) for people who weren't there, a 1 for people who are there, and a -1 for people who are there but didn't go caving.
This is adding an extra column to every line in the file.
<p>
Add new lines for new people, with the right number of columns.
<p>This process is tedious and error-prone and ripe for improvement especially as expo proceeds and youhave many more names to add. Adding a list of people from the bier book and their aliases (the name in brackets) would be a lot better, but some way to make sure that names match with previous years would be good.
<p>
Contrary to what you might expect we find that it is much more reliable to edit this using a text editor rather than a spreadsheet program.
<p>The nerd can log in using the 'expo' userid.
<p>The nerd needs to do this:
<ol>
<li>Upload the edited copy of folk.csv to the server using the version control system.
<li>Log in to the expo server and run the update script (see below for details)
<li>Watch any error messages scroll by.
<li>Look at the new folk list HTML file at <a href="http://expo.survex.com/folk/">http://expo.survex.com/folk/</a>
<li>Re-run the import script until you have got rid of all the import errors.
</ol>
<p>This is how you login and run the script:
<pre><code>ssh expo@expo.survex.com
cd folk
python ../scripts/make-folklist.py &lt;folk.csv &gt;index.htm
</code></pre>
<p>If there are no errors, you will just see this on your ssh session:
<pre><codeLoading expeditions
Loading personexpeditions
</code></pre>
<p>And you will see the result online at <a href="http://expo.survex.com/folk/">http://expo.survex.com/folk/</a>.
<p>It is recommended that the nerd does this locally on their own laptop first. It does not need to be an expo laptop, even a Windows 10 laptop is fine if the script is run in a WSL terminal. The only software you need to install is the default python package.
<hr />
</body>
</html>

16
handbook/computing/keyexchange.html
View File

@@ -2,7 +2,7 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Handbook placeholder page</title>
<title>Key-Pair Setup (Expo handbook)</title>
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head>
<body>
@@ -20,7 +20,7 @@
<p>Explanation of <a href="https://www.ssh.com/ssh/keygen/">key-pairs and the ssh-keygen command</a>.</p>
<p>A public key file looks like this: <tt>ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApc9+PAMrDtWa8D8/ZneLP2X9UOYmTITAhTd2DRs8SE+NDgis5pYo/Xhtbrg86ePMAC2YM5xAkYx3jNA/VZ/PkB3gTzYJW3T/zTH+cc7YeWhy9l1zIMaYqeyvw7FxeSBaR4XoLPVtVUlai8DUDiWAEm7VvOKj1n68z1LxVh1MZXLm7btckf6fske2YU9UpjqT++AURQvFheRJ4la7KBJ7LXZ3A/TQ7HQaTpqmcQKCiRj/yZ5FNHxBk0M+ShbHUtz1GhXRCMJ3LZHaw24OJyVJ8YNzBiStBb1qcWCXX7HR9CUNhz7tA5HZyc1lau/1vwk8MSe93lyyLntzJKkqmkW/cQ== wookey@kh</tt>i.e. a long string of characters with 'ssh-rsa' at the start and a 'user'@'machine' ID at the end.</p>
<p>A public key file looks like this: <tt>ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApc9+PAMrDtWa8D8/ZneLP2X9UOYmTITAhTd2DRs8SE+NDgis5pYo/Xhtbrg86ePMAC2YM5xAkYx3jNA/VZ/PkB3gTzYJW3T/zTH+cc7YeWhy9l1zIMaYqeyvw7FxeSBaR4XoLPVtVUlai8DUDiWAEm7VvOKj1n68z1LxVh1MZXLm7btckf6fske2YU9UpjqT++AURQvFheRJ4la7KBJ7LXZ3A/TQ7HQaTpqmcQKCiRj/yZ5FNHxBk0M+ShbHUtz1GhXRCMJ3LZHaw24OJyVJ8YNzBiStBb1qcWCXX7HR9CUNhz7tA5HZyc1lau/1vwk8MSe93lyyLntzJKkqmkW/cQ== wookey@kh</tt>i.e. a long string of characters with 'ssh-rsa' at the start and an ID at the end (often 'user'@'machine').</p>
<h3>Windows</h3>
<p>On a Windows machine use
@@ -28,8 +28,11 @@
<p>Follow the Puttygen instructions, but the really short version is:
<li>Run PuTTYgen</li>
<li>Click on 'Generate'. Follow the instructions. Don't bother adding a passphrase.</li>
<li>Save the key</li>
<li>Copy all of the public key out of the window and paste that into the email. Make sure not to miss part or add newlines or otherwise mess with it.</li>
<li>Type your name in the 'Key comment' field. (just so we know who's key it is)</li>
<li>Save the private key (this will create a .ppk file that you will need later)</li>
<li>Don't save the public key - instead copy all of the text from the 'Public key for pasting
+into OPENSSH authorized_keys file' field, and paste that into the email. Make sure not to miss part or add newlines or otherwise mess with it.</li>
<li>Run Pageant (it will have been installed in your Start menu, otherwise find it it "C:\Program Files\PuTTY\pageant.exe"). Click the "Add Key" button. Select the .ppk file in the pop-up file list. You only need to do this once.
</ol>
<h3>Linux</h3>
@@ -39,7 +42,6 @@
<li>If not, run <tt>ssh-keygen</tt>. It may ask about passwords: you can add a password for extra
security, but a passwordless key is fine, and more convenient.</li>
<li>That will create a file: <tt>.ssh/id_rsa.pub</tt> in your home directory. Email that file to one of the admins listed above. </li>
<li>Run Pageant (it will have been installed in your Start menu, otherwise find it it "C:\Program Files\PuTTY\pageant.exe"). Click the "Add Key" button. Select the .ppk file in the pop-up file list. You only need to do this once.
</ol>
@@ -62,7 +64,7 @@
<h2>Your second machine</h2>
<p>OK, you have an uploaded and usable key and you can ssh into the expo server. Now you want to set up a key for another machine such as your phone. You don't need a nerd admin now, you can do this yourself. But be <b>extremely careful</b> to follow this exactly. If you innocently rename the files to something that appears more sensible it won't work.
<p>OK, you have an uploaded and usable key and you can ssh into the expo server. If you want to connect from another machine (e.g. your phone) it's better to make another key than try to re-use the first one. You don't need a nerd admin now, you can do this yourself. But be <b>extremely careful</b> to follow this exactly. If you innocently rename the files to something that appears more sensible it won't work.
<ol>
<li>On your new machine, generate a key-pair. Since you are probably using a different operating system on your second machine, read the instructions above for the relevant OS. Yes you will be generating a new key. Do not re-use the key you had already.
<li>This time though, you will want to be sure that the key has a meaningful label. On Linux this means something like this:
@@ -73,7 +75,7 @@ If you accepted the defaults, the public key will be called <span style="font-fa
<li>Now copy the public key file to your <em>first machine</em>, the one that is already set up with a working key-pair setup with the expo server. Using email to yourself is easiest.
<li>Now upload the public key using sFTP (Filezilla configured to use sFTP, which uses Pageant by default) to <span style="font-family:monospace; size=x-small; background-color: lightgray">expo.survex.com/home/expo/.ssh/keys/</span>
<li>Now login to the expo server on your first machine and do these commands:<br>
Be <b>extremely careful</b> to type ">>" and not ">" in the fourth line below otherwise you will delete everything.
Be <b>extremely careful</b> to type ">>" and not ">" in the fourth line below otherwise you will delete <i>everyone's</i> logins.
<tt><font color=red">$</font> ssh expo@expo.survex.com
<br><font color=blue">expo@expo:~$</font> cd .ssh
<br><font color=blue">expo@expo:~$</font> cp -p authorized_keys authorized_keys.backup

278
handbook/computing/menudesign.html Normal file
View File

@@ -0,0 +1,278 @@
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>CUCC Expedition Handbook: Website menu design options</title>
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head>
<body>
<h2 id="tophead">CUCC Expedition Handbook - Website menu design options</h2>
<h1>What, How and Why : New menus</h1>
<ul>
<li><a href="#why">Why</a>
<li><a href="#whatold">What we have now (appendix)</a>
<li><a href="#maint">Maintenance constraints</a>
<li><a href="#user">User mental model constraints</a>
<li><a href="#prop1">Proposal #1</a>
<li><a href="#prop2">Proposal #2</a>
<li><a href="#offline">Offline constraints (appendix)</a>
</ul>
<h2 id="why">Menus: Why we need a change now</h2>
<h4>Phones</h4>
<p>The <a href="#whatold">current system</a> makes it very difficult to design menus that work on phone screens.
Phones are now the primary access method and the current menus actively get in the way rather than provide useful function.
They have to be fixed.
<h4>Higher level, lower-level menus and context</h4>
<p>
Secondly, we observe that many users never look at the menus. From using other websites they are used to seeing the important links in the text of the page
they are reading. This is particularly true for pages documenting a
sequence of operations such as the <em>sketch-wallet-survex-drawings</em> sequence. This is also how well-designed websites work these days: lots of white
space and any necessary navigation clearly <em>in</em> the page.
<p>
An excellent guide is the
<a href="https://www.gov.uk/guidance/government-design-principles">gov.uk design principles</a>
web pages which practice what they preach. They have a "Related Content" menu to one side,
breadcrumbs showing the page context, more remote organisation menu along the top of the page and two
or three fine-print menus at the bottom of the page for potentially relevant standard stuff.
<p>Users need "situational awareness" in that they like to know "where they are" in the system. This is not the same thing as a menu list of links to "places you might like to go to". But these two different things are both called "navigation". The gov.uk design guide separates these two things and we should too.
<p>Another reason that users don't use the menus is inconsistency. This is partly because the menus don't
match the <a href="#user">mental model they have</a> of how the system is put together and partly
because <a href="#maint">maintenance difficulties</a> have created
an inconsistent system.
<p>The menu system we created a decade ago was leading-edge in its time but user expectations have moved in a different direction.
<h2 id="maint">Menus: Maintenance constraints</h2>
<p>
Experience over the past 10 years shows that having menus embedded in each page (see <a href="#whatold">What we have now</a>) is
unworkable long-term.
<p>
People create new pages typically by editing a copy of the last page they edited.
This might have been from an entirely different part of the system.
So we end up with "survey documentation" menus on a page which is in the middle of a "basecamp operations" set of pages.
We cannot control the behaviour
of page editors and we are very grateful to them so we don't want to add to their workload or make
things messy or difficult.
<p>See the Proposals sections below for how we might make this easier.
<p>A maintenance constraint is that we should have <em>a small number</em> of different menus.
<h2 id="user">Menus: User mental model constraints</h2>
<p>This is where we have a real problem. Even nerds editing the system have different ideas
of how they visualise it.
<p>Most users have no picture at all of the distinctions between "the handbook",
the "local area", the "cave survey data", the "software maintainers guide" parts.
Some people only interact with only one part of the system and are entirely
unaware of the rest of the system.
<p>Some pages which are definitely in the mental "how to do expo" category are not just hand-edited handbook webpages,
for example some prospecting guides are generated from cave data.
<p>Some pages have to be updated very differently fom others. The "cave descriptions" are particularly difficult for
someone used only to interacting with an HTML editor or a wiki. But for most users this distinction is invisible.
<p>The current set of menus suffer greatly from "bleed through" in that they mimic the hidden internal structure
of the system rather
than (as they should) the user mental model of how users want to interact with it.
<p>A user mental model constraint is that menus should be predictable,
so we should have <em>a small number</em> of different menus.
<h2 id="prop1">Menus: Proposal #1 - One Single Menu</h2>
<h4>Architecture</h4>
<ul>
<li>One standard menu used on every single page.
<li>Generated dynamically by troggle.
</ul>
<p>This will need quite a bit of thought and discussion as to what should be in the menu.
We should test this with a variety of real users, or roll it out and be very responsive to change requests.
<h4>Implementation</h4>
<ul>
<li>Entirely done in CSS as currently, and
<li>inserted by troggle either just before the final
<span style="font-family:monospace; font-size: medium; background-color: lightgray">&lt;/body&gt;</span>
tag or at the beginning immediately after the initial
<span style="font-family:monospace; font-size: medium; background-color: lightgray">&lt;body&gt;</span>
tag.
<li>A bit of tricky awk required to remove all the tags with
<span style="font-family:monospace; font-size: medium; background-color: lightgray">id="links"</span>
attributes. But just an evening's work.
</ul>
<h4>Advantages</h4>
<ul>
<li>Excellent predictability for users
<li>Simple to implement: minimal changes to the existing system.
<li>No effort whatsoever on page editors and content typers
<li>No conflicting menus from different sources appearing on the same page
<li>"Edit this page" can appear or not depending on user authorisation or (for generated pages) entirely absent.
<li>Universal single update: change once changes menus for whole system
</ul>
<h4>Disadvantages</h4>
<ul>
<li>No menus offline
<li>No fine-grained menu when in the middle of a complex part of the system
</ul>
<h2 id="prop2">Menus: Proposal #2 - Different menus per "sector"</h2>
<h4>Architecture</h4>
<ul>
<li>Every page in the system is identified (how?) as being "in" one of half a dozen "sectors", e.g.
handbook, handbook-emergency, final cave data, survey procedures, software documentation, software maintenance etc.
<li>troggle inserts the menu dynamically depending on the page "sector" id.
</ul>
<h4>Implementation</h4>
<ul>
<li>All programmed within troggle
<li>page editors will need to insert an identifying tag, OR
<li>we restructure the folders completely and have troggle use the folder structure to decide which "sector" is which
</ul>
<h4>Advantages</h4>
<ul>
<li>Fine-grained menus potentially more useful (if users use them)
</ul>
<h4>Disadvantages</h4>
<ul>
<li>Will need visible flagging to users which "sector" they are in,
otherwise the different menus appearing may disorient them
<li>If implemented by folder restructuring: all links in to the website, e.g. in historic emails, all the Slack posts, all the UKcaving blog posts etc. etc.
will <em>break</em> unless we create a large redirection list in the apache configuration files.
<li>If implemented by manual tag insertion in every page: page editors will get it wrong sometimes (but each fix is easy)
</ul>
<h2 id="prop2">Menus: Proposal #3</h2>
<p>Do Proposal #1 now.
<p>Do Proposal #2 later - if it turns out to be needed. (Probably by tag method not folder method.)
<p>&nbsp;
<p>
<h2 id="whatold">Appendix - Menus: What we have now</h2>
<p>Today (February 2020) we have two separate menu systems which look identical:
<ol type=A >
<li>Menu links as HTML text on individual webposite pages, either hand-edited (handbook) or
generated as HTML pages by occasional offline scripts (such as the deep/long caves page) , or
<li>Auto-created menus constructed <em>on the fly</em> by troggle at the moment that a page is served by the webserver.
This happens for every single page of every type.
</ol>
<h4>Type A - static menus</h4>
<p>The first type, the "static"menus, are created by HTML like this, with a
<span style="font-family:monospace; font-size: medium; background-color: lightgray">id="links"</span>
tag attribute which creates the styling:
<pre><code>&lt;!-- LINKS --&gt;
&lt;div id="menu"&gt;
&lt;ul id="links"&gt;
&lt;a href="index.htm"&gt;Handbook&lt;/a&gt;
&lt;a href="survey/index.htm"&gt;Surveying&lt;/a&gt;
&lt;a href="look4.htm"&gt;Prospecting&lt;/a&gt;
&lt;a href="rescue.htm"&gt;Rescue&lt;/a&gt;
&lt;/ul&gt;
&lt;/div&gt;</code></pre>
<p>This text is conventionally at the bottom of each HTML file. (It does not have to be at the bottom,
the CSS handles where on the page this appears visually, so this HTML fragment could be anywhere
in the HTML file.)
<p>The visual rendering of the menus is controlled by lines 120-215 in <a href="../../css/main2.css">main2.css</a> -
thanks to a succession of clever and inventive people.
<p><p>
Here is an example of a more extensive menu. Note that changes to CSS over the years now mean that this
overflows the menu box because the annotations are too long for the box width:
<pre><code>&lt;!-- LINKS --&gt;
&lt;div id="menu"&gt;
&lt;ul id="links"&gt;
&lt;li&gt;&lt;a href="index.htm"&gt;Expedition Handbook&lt;/a&gt; - Intro
&lt;ul&gt;
&lt;li&gt;&lt;a href="survey/index.htm"&gt;Surveying guide&lt;/a&gt; - Overview&lt;/li&gt;
&lt;li&gt;&lt;a href="look4.htm"&gt;Prospecting guide&lt;/a&gt; &ndash; Overview
&lt;li&gt;&lt;a href="rescue.htm"&gt;Rescue guide&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="rig/rigit.html"&gt;Rigging guide&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="photo.htm"&gt;Photography guide&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="../infodx.htm"&gt;Index to info/topics pages&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="../indxal.htm"&gt;Full Index to area 1623&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="../areas.htm"&gt;Area/subarea descriptions&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="../index.htm"&gt;Back to Expedition Intro page&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="../../index.htm"&gt;Back to CUCC Home page&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;</code></pre>
<p>There are <span style="text-decoration: line-through wavy red;">a few</span> 546 pages (out of hand-edited 1,022 HTML pages) where the enclosing
<span style="font-family:monospace; font-size: medium; background-color: lightgray">DIV</span>
tag is omitted. In these cases troggle inserts its own menu <em>in addition to</em> the static menu. The result is a confusion of two menus. These pages are in currently being identified and corrected.
<h4>Type B - dynamic (troggle) menus</h4>
<p>This menu is a fragment of HTML inserted by troggle on the fly as the page is served to the user.
It is inserted immediately before the closing
<span style="font-family:monospace; font-size: medium; background-color: lightgray">&lt;/body&gt;</span>
tag.
It has one thing which cannot be done by static menus: it has the <font color=red>"Edit this page"</font> link
at the bottom which is the troggle (Django) wiki-style editing system:
<pre><code>&lt;ul id="links"&gt;
&lt;li&gt;&lt;a href="/index.htm"&gt;Home&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/infodx.htm"&gt;Main Index&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/troggle"&gt;Troggle&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/areas.htm"&gt;Areas&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/indxal.htm"&gt;Caves&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/handbook/index.htm"&gt;Handbook&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/pubs.htm"&gt;Reports&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/handbook/<font color=red>menudesign.html_edit</font>" <font color=red>class="editlink"</font>&gt;&lt;strong&gt;<font color=red>Edit this page</font>&lt;/strong&gt;&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</code></pre>
<p>Note that the last line is different for every page and autogenerated.
<p>
The dynamic menu is rendered by exactly the same CSS
<span style="font-family:monospace; font-size: medium; background-color: lightgray">id="links"</span>
as the static menu.
<p>Note that there is no
<span style="font-family:monospace; font-size: medium; background-color: lightgray">&lt;div id="menu"&gt;</span> enclosing
<span style="font-family:monospace; font-size: medium; background-color: lightgray">DIV</span>
tag. The
<span style="font-family:monospace; font-size: medium; background-color: lightgray">DIV</span>
tag is only there to tell troggle that there is a static menu and so it shouldn't provide one.
<p>For the past 3 years the static menus have been mostly removed from edited pages as the dynamic menu did the job, and
often both would appear which was ugly. This page has both menus:
<a href="http://expo.survex.com/dplong.htm">Lengths and depths of caves in the 1623 area</a>.
<h2 id="offline">Appendix - Menus: Offline constraint</h2>
<p>It is handy if a completely offline copy of the website
- just the HTML files and CSS - still has a useable (if cut-down) menu system. (This used to be vital when the potato hut
server troggle stopped but the server could still provide HTML files. Not any more.)
But this is increasingly unnecessary for most of the people using it.
<p>The most likely use-case would be someone on the plateau (or possibly underground)
needing to read the handbook pages on rescue or first-aid procedures using a locally-stored copy
of the entire handbook. Most people won't have done in this in advance of the need or wouldn't know how
to do it anyway. If they can do this, they are not likely to be relying on the menu system to find what they want.
<p>Can anyone think of other cases where menus for offline use might be useful?
<h4>Files for download as an alternative</h4>
<p>We could meet this very specific requirement without messing with our menus. We could have a complete set of
downloadable documents (e.g. PDF) of prospecting guides and safety procedures - including topcamp and basecamp phone numbers -
which we encourage all expoers to download to their phone before they leave base-camp.
We already have a number of these but some are in .odt format which is not phone-friendly. But that is another job to fix.
<hr>
</body>
</html>

13
handbook/computing/newyear.html
View File

@@ -38,17 +38,8 @@
<li>create initial versions of the bierbook and the seshbook in expoweb/documents/bierbook (the final copies after expo will be scanned and put in e.g. expofiles/writeups/2020/ along with the scanned logbook).
<li>copy the contents of the previous year's expoweb/years/ folder, e.g. /2019/ to 2020/ and edit all the files therein. You should start with at least an index.html and a mission.html
</ul>
<p>Edit folk/folk.csv, adding the new year to the end of the header
line, a new column, with just a comma (blank
cell) for people who weren't there, a 1 for people who were there, and
a -1 for people who were there but didn't go caving. Add new lines for
new people, with the right number of columns.</p>
<p>This proces is tedious and error-prone and ripe for improvement.
Adding a list of people, from the bier book, and their aliases would be
a lot better, but some way to make sure that names match with previous
years would be
good.</p>
<p>Edit folk/folk.csv according to the instructions in the <a href="folkupdate.html">Folk Update process</a>
</p>
Return to the main <a href="../manual.html">online systems manual</a>.

19
handbook/finance.html
View File

@@ -110,14 +110,14 @@ it before obtaining the expedition treasurer’s agreement.</li>
<UL>
<LI>Their expenditure on behalf of Expo </LI>
<LI>Their travel as part of Expo </LI>
<!--<LI>Their travel as part of Expo </LI>-->
<LI>The length of time they spend on Expo (from food, camping &amp; travel in Austria costs) </LI>
<LI>The number of nights at basecamp - tourist tax is due on camping fees </LI>
<LI>The number of nights up the mountain - for topcamp food and equipment </LI>
<LI>Whether they go caving (the equipment expenditure is divided equally among the cavers) </LI>
<LI>Personal costs, such as bier, insurance, T-shirts </LI>
<LI>Any swaps they have made with other expedition members </LI>
<LI>Whether they are employed or not and whether Expo received any grants. </LI>
<!--<LI>Whether they are employed or not and whether Expo received any grants. </LI>-->
<li>Whether they have received an Expo Bursery
</UL>
@@ -135,12 +135,17 @@ it before obtaining the expedition treasurer’s agreement.</li>
<H4>Gone caving</H4>
<P>In the past the cost of equipment purchase and maintenance were divided equally among everyone who went caving, usually irrespective of how long they were on Expo; this was to encourage people to make good use of the gear and make it easier for people (often students) to spend the full 5 weeks on Expo. [The <EM>caver</EM> fiddle factor (normally either 0 or 1) is used in applying this charge]. In recent years this policy has been modified to more precisely represent the costs, and encouragement of poor students done through a separate bursery mechanism.</P>
<P>In the past the cost of equipment purchase and maintenance were divided equally among everyone who went caving, usually irrespective of how
long they were on Expo; this was to encourage people to make good use of the gear and make it easier for people (often students) to spend the
full 5 weeks on Expo.
<!--[The <EM>caver</EM> fiddle factor (normally either 0 or 1) is used in applying this charge]. -->
In recent years this
policy has been modified to more precisely represent the costs, and encouragement of poor students done through a separate bursery mechanism.</P>
<H4>Personal costs</H4>
<P>The popular/cheap Austrian Bier <EM>G&ouml;sser</EM> is bought communally. Each member's bier consumption is recorded in <a href="bierbook.html">the Bier Book</a> and the appropriate amount charged to them. A similar scheme operates for lemonade and radler.</P>
<P>The popular/cheap Austrian Bier <EM>G&ouml;sser</EM>, better beer <EM>Dunkel</EM>, lemonades <EM>Limos</EM>, and shandy-type concoctions <EM>Radlers</EM> are bought communally in crates in returnable bottles. Each member's bier consumption (all types of drink) is recorded in <a href="bierbook.html">the Bier Book</a> and the appropriate amount charged to them.
@@ -158,11 +163,13 @@ it before obtaining the expedition treasurer’s agreement.</li>
<H4>Expo grants</H4>
<P>Grants may come from the GPF, other funding bodies or through students from their college. Expo sometimes uses some of this money to purchase specific high capital items; in 1999 this was a six-berth tent and two mobile phones, in 2018 it was for half a Cavelink radio system. The remaining money may be managed as a bursery or divided amongst the unwaged members on Expo, using the <EM>grantshare</EM> fiddle factor. <EM>Grantshare</EM> ranges from 0 for no entitlement to 1 for full entitlement.</P>
<P>Grants may come from the GPF, other funding bodies or through students from their college. Expo sometimes uses some of this money to purchase specific high capital items; in 1999 this was a six-berth tent and two mobile phones, in 2018 it was for half a Cavelink radio system. The remaining money (if any) may be managed as a bursery or put towards next year's float.
<!--divided amongst the unwaged members on Expo, using the <EM>grantshare</EM> fiddle factor. <EM>Grantshare</EM> ranges from 0 for no entitlement to 1 for full entitlement.-->
</P>
<H4 id="rights">Intellectual property rights</H4>
<p>
Photographers retain copyright of their material, but give Expo the 'right to reproduce' their photographs for Expo and CUCC journals, slideshows, etc. This assignment of right to reproduce is assumed when a member arrives at expo. <!--See David Gibson's thoughts on this in appendix F (MISSING!).-->
Photographers retain copyright of their material, but give Expo the 'right to reproduce' their photographs for Expo and CUCC journals, slideshows, etc. This assignment of right to reproduce is assumed when a member arrives at expo. The same goes for all writing in logbooks, callout books, survey notes, website handbook, whiteboards or any other expo-related format<!--See David Gibson's thoughts on this in appendix F (MISSING!).-->
<p>Now read about <a href="treasurer.html">How to be the expo treasurer</a>.

3
handbook/leader.htm
View File

@@ -41,6 +41,9 @@ gear out to Austria, on a shoestring budget with a limited number of
cars, and people coming-from/going-to various places are
daunting. The job mostly involves collating info and badering people
regularly. Starting early saves everyone money. See the explicit <a href="transport.html">transport checklist and guide</a>. </dd>
<dt>Survey marshalling and Kataster chief</dt>
<dd>If the previous expo's survey marshal did a good job then this can be straightforward, otherwise finding and recording the records needed to make sure that survey is in a fit state to support future exploratipon can be heartbreaking and frsutrating. The non-survey data archiving also needs doing carefully, such as curating the list of equipment left at top camp and ensuring that the logbook entries are all typed up and parsed into the expo server.</dd>
<dt>Caving Priorities</dt>
<dd>This should be the fun bit, but thee is a long grind in getting the previous years' survey data and QMs sorted out - the previous years expoers will need a lot of chivvying.</dd>
<dt>Project officers</dt>

130
handbook/logbooks.html
View File

@@ -1,5 +1,7 @@
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>CUCC Expedition Handbook: The Website</title>
<link rel="stylesheet" type="text/css" href="../css/main2.css" />
</head>
@@ -7,32 +9,54 @@
<h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Logbooks</h1>
<p>As soon as possible after a trip finishes, a <b>hand-written write-up</b> of the trip is made in the nearest logbook:
the base camp logbook or the top camp logbook. All these logbook entries are then typed into a laptop (often the expo laptop)
which is then synchronised the version control system.
the base camp logbook or the top camp logbook.
<p>Recent logbooks:
<ul>
<li><a href="../years/2019/logbook.html">2019</a>
<li><a href="../years/2018/logbook.html">2018</a>
<li><a href="../years/2017/logbook.html">2017</a>
<li><a href="#why">Why</a> the logbook is so important
<li><a href="#type">Typing on the <em>Expo Laptop</em></a>
<li><a href="#another">Typing on another laptop</a>
<li><a href="#format">Formatting</a> a typed logbook entry
</br></br>
<li><a href="#import">Importing</a> the logbook into troggle (nerds only) - error checking
<li><a href="#history">Historical</a> logbookformat (nerds only)
</ul>
<h3 id="why">Why the logbook is important</h3>
<p>The logbook writeup is the oldest and most basic way of recording your trip but it must not be neglected. This is also where you put
your speculations and ideas for what looks promising and what is obvious but doesn't go: things that are vital to future expoers. And please, please
do lots of sketches in the logbook.
<p>If you are at basecamp, then it is an excellent idea to
<b>type your logbook trip report</b> instead of writing it by hand - see <a href=#type">below</a>.
<p>The contents of both the topcamp logbook and the basecamp logbook are typed into the same
"logbook.html" file for archiving. The drawings are scanned and stored in the same place, and hand-edited
into the logbook.html file after expo finished.
<p>Always, always write the date, <em>your</em> name and the names of other people involved at the top of each entry.
If you mention a cave location, please also write down the cave name somewhere. In 10 years no-one will know
where "Lemon Snout" is.
<p>If this is all new to you, please now read <a href="datamgt.html">Cave data management</a>,
and <a href="survey/why.htm">why we make surveys</a> and then the
<a href="survey/index.htm">Survey Handbook</a>
<p>If you are at basecamp, then it is an excellent idea to
<b>type the text of your logbook trip report</b> instead of writing it by hand - see <a href="#type">below</a>. But still do lots of drawings in the paper logbook.
<p>The contents of both the topcamp logbook and the basecamp logbook are typed into the same
"logbook.html" file for future use in tracking down leads and surveys. The drawings are scanned and stored in the same place, and hand-edited
into the logbook.html file after expo finished. The typed notes are uploaded into the expo server database and
correlated with survey data done on the same day or by the same people.
<p>Recent logbooks:
<ul>
<li><a href="../years/2018/logbook.html">2018</a>
<li><a href="../years/2017/logbook.html">2017</a>
</ul>
<p>All these logbook entries are then typed into a laptop (often the expo laptop)
which is then synchronised the version control system.
<p>The result is a webpage reporting who did what and what was done by whom on expo,
e.g. see <a href="http://expo.survex.com/expedition/2018">the 2018 expo report</a>.
<h3 =id="type">Typing just your trip report (at the <i>Expo Laptop</i>)</h3>
<p>If you are at basecamp, then it is an excellent idea to type up your logbook trip report.
You can then print this and stick it in the logbook, adding any sketches by hand.
@@ -60,11 +84,13 @@ Then start it up again from the vertical icon menu as before.
<p>Now type in your trip report using whatever format you like, but please leave a blank line between paragraphs.
<h3>Adding your trip to the logbook online file</h3>
<p>If you are using the <em>expo laptop</em> just edit this file:
<pre>
/home/expo/expoweb/years/2018/logbook.html
</pre>
<h4>Adding your trip to the logbook online file</h4>
<p>If you are using the <em>expo laptop</em> just edit this file (if you are on expo in 2025):
<code>
/home/expo/expoweb/years/2025/logbook.html
</code>
copy the format you can see other people have used;
and other people will take care of synchronising it with the version control system.
@@ -83,46 +109,84 @@ ensure that the updates from all the people entering trip data are OK and don't
<p>Logbooks are typed up and kept in the [expoweb]/years/[nnnn]/ directory as 'logbook.html'.</p>
<h3>Recommended procedure (on another machine)</h3>
<h3 id="another">Typing on another machine</h3>
<p>
Rather than editing logbook.html when you type up your trip, it is a much better
idea to type up <i>just your trip(s)</i> in a separate file, e.g. "logbook-mynewtrip.txt", and email it to a nerd if you are sitting at a different laptop.
<h3>Format of the online logbooks</a></h3>
<h3 id="format">Format of the online logbooks</a></h3>
<p>Do whatever you like to try and represent the logbook in html. The only rigid structure is the markup to allow troggle to parse the files into 'trips':</p>
<pre>
<code><pre>
&lt;div class="tripdate" id="t2007-07-12B"&gt;2007-07-12&lt;/div&gt;
&lt;div class="trippeople"&gt;&lt;u&gt;Jenny Black&lt;/u&gt;, Olly Betts&lt;/div&gt;
&lt;div class="triptitle"&gt;Top Camp - Setting up 76 bivi&lt;/div&gt;
&lt;div class="timeug"&gt;T/U 10 mins&lt;/div&gt;
</pre>
&lt;div class="timeug"&gt;T/U 10 mins&lt;/div&gt;</pre></code>
<p>Note that the ID's must be unique, so are generated from 't' plus the trip date plus a,b,c etc.
when there is more than one trip on a day.</p>
<p>T/U stands for "Time Underground" in hours (6 minutes would be "0.1 hours").
<hr />
<h3>Historical logbooks</h3>
<h3 id="history">Historical logbooks</h3>
<p>Older logbooks (prior to 2007) were stored as logbook.txt with just a bit of consistent markup to allow troggle parsing.</p>
<p>The formatting was largely freeform, with a bit of markup ('===' around header, bars separating date, <place> - <description>, and who) which allows the troggle import script to read it correctly. The underlines show who wrote the entry. There is also a format for time-underground info so it can be automagically tabulated.</p>
<p>So the format should be:</p>
<pre>
===2009-07-21|204 - Rigging entrance series| Becka Lawson, Emma Wilson, Jess Stirrups, Tony Rooke===
&lt;Text of logbook entry&gt;
<code>
===2009-07-21|204 - Rigging entrance series| Becka Lawson, Emma Wilson ===
</br>
&#123;Text of logbook entry&#125;
</br>
T/U: Jess 1 hr, Emma 0.5 hr
</pre>
</code>
<h3 id="import">Importing the logbook into troggle</a></h3>
<p>This is usually done after expo but it is in excellent idea to have a nerd do this a couple of times during expo to discover problems while the people are still around to ask.
<p>The nerd needs to login to the expo server using <em>their own userid</em>, not the 'expo' userid. The nerd also needs to be in the group that is allowed to do 'sudo'.
<p>The nerd needs to do this:
<ol>
<li>Look at the list of pre-existing old import errors at </br> <a href="http://expo.survex.com/admin/core/dataissue/">http://expo.survex.com/admin/core/dataissue/</a> </br>
The nerd will have to login to the troggle management console to do this, not just the usual troggle login.
<li>You need to get the list of people on expo sorted out first. </br>
This is documented in the <a href="computing/folkupdate.html">Folk Update</a> process.
<li>Log in to the expo server and run the update script (see below for details)
<li>Watch the error messages scroll by, they are more detailed than the messages archived in the old import errors list
<li>Edit the logbook.html file to fix the errors. These are usually typos, non-unique tripdate ids or unrecognised people. Some unrecognised people will mean that you have to fix them using the <a href="computing/folkupdate.html">Folk Update</a> process first.
<li>Re-run the import script until you have got rid of all the import errors.
<li>Pat self on back. Future data managers and people trying to find missing surveys will worship you.
</ol>
<p>The procedure is like this. It will be familiar to you because
you will have already done most of this for the <a href="computing/folkupdate.html">Folk Update</a> process.
<pre><code>ssh {youruserid}@expo.survex.com
cd ~expo
cd troggle
sudo python databaseReset.py logbooks
</code></pre>
<p>It will produce a list of errors like this, starting with the most recent logbook which will be the one for the expo you are working on.
You can abort the script (Ctrl-C) when you have got the errors for the current expo that you are going to fix
<pre><code>Loading Logbook for: 2017
- Parsing logbook: 2017/logbook.html
- Using parser: Parseloghtmltxt
Calculating GetPersonExpeditionNameLookup for 2017
- No name match for: 'Phil'
- No name match for: 'everyone'
- No name match for: 'et al.'
("can't parse: ", u'\n\n&lt;img src="logbkimg5.jpg" alt="New Topo" /&gt;\n\n')
- No name match for: 'Goulash Regurgitation'
- Skipping logentry: Via Ferata: Intersport - Klettersteig - no author for entry
- No name match for: 'mike'
- No name match for: 'Mike'</code></pre>
<hr />
<ul id="links">
<li><a href="index.htm">Expedition Handbook</a>
</ul>
</body>
</html>

7
handbook/manual.html
View File

@@ -50,7 +50,7 @@ processes that a maintainer would want to do.</p>
<li><a href="#cavepages">Updating cave pages</a></li>
<li><a href="#updatingyears">Updating expo year pages</a></li>
<li><a href="#surveystatus">Maintaining the survey status table</a></li>
<li><a href="#automation">Automation</a></li>
<li><a href="#menu">Cave pages and handbook menu system</a></li>
</ol>
Appendices:
@@ -274,6 +274,11 @@ superseded in 2012).</p>
<li>This used to be generated by the script tablizebyname-csv.pl from the input file Surveys.csv
</ul>
<h3><a id="menu">Cave pages and handbook menu design</a></h3>
<p>See the <a href="computing/menudesign.html">menu design history and proposals</a>
page on where we are and what we might do to improveand fix menus.
<hr />
</body>
</html>

11
handbook/planning.html
View File

@@ -25,8 +25,17 @@
<dt><a href="transport.html">Transport: getting people and gear to Expo</a></dt>
<dd>This is complicated and difficult and much of the effort happens during June. </dd>
<dt><a href="survey/status.html">Kataster & Survey: getting survey data reported to Austrians and prep. for next expo</a></dt>
<dd>Some of this needs to happen immediately after the previous expo before things get lost, the rest over Christmas. </dd><ul>
<li><a href="computing/newyear.html">Create new year</a> - create new website & server folders ready for next expo</li>
<li><a href="transport.html">Who/When</a> - create table for tracking who is coming to expo and when</li>
<li><a href="http://expo.survex.com/expedition/2018">Logbooks & trips</a> - tidy up last bits of trip records from last year</li>
</ul>
<dt>Planning who does what</dt>
Read the expo leader checklist (above). Consult the planning lists from previous expos:
<dd>Read the expo leader checklist (above). Consult the planning lists from previous expos:</dd>
<ul>
<li><a href="../years/2002/todo.html">2002</a> - to do list</li>
<li><a href="../years/2007/jobs.html">2007</a> - allocating jobs to people</li>

2
handbook/survey/newcave.html
View File

@@ -198,7 +198,7 @@ ensure that it is <em>saved, committed, </em>and<em> pushed</em> appropriately.
<p>[Nerds: survex cave data belongs in the repository "loser", e.g.
loser "caves-1623/264/mongolrally.svx". We are assuming that normal users have never
worked with an distributed version control system at this point whcih is why we are only
worked with an distributed version control system at this point which is why we are only
telling them to use the <em>expo laptop</em>.]
<h3><a id="tickingoff">Ticking off QMs</a></h3>

15
handbook/survey/status.html
View File

@@ -13,24 +13,29 @@
<p>There are two separate online systems to help you do this.
<p>First, you look online at or for the current year: (2018 in this example)<br>
<p><b>First</b>, you look online at or for the current year: (2018 in this example)<br>
<a href="http://expo.survex.com/expofiles/surveyscans/2018/index.html"><b>/expofiles/surveyscans/2018/</b></a>
<br>
(you can substiute any year after 2015 instead of 2018 in that example).
(you can substitute any year after 2015 instead of 2018 in that example).
<p> or if you are chasing work unfinished from previous years look at the consolidated list 2014-2018:<br>
<a href="http://expo.survex.com/expofiles/surveyscans/2014-18/index.html"><b>/expofiles/surveyscans/2014-18/</b></a>
<br>
<p>Second, look at the online troggle-generated table of logbook entries and survey trips<br>
<p><b>Second</b>, look at the online troggle-generated table of logbook entries and survey trips<br>
<a href="http://expo.survex.com/expedition/2018"><b>/expedition/2018/</b></a>
<br>
(You need to scroll down past the table of attendees). This expedition report only shows those cave surveys which have been both typed up and entered into the online system, and also only those logbook entries which have been typed up already. So it will not be as up to date as the first method.
<p>The most up to date method is to look in the lever-arch file containing the plastic survey wallets which is kept in the potato hut during expo.
<p>The online wallet system and how it works are <a href="newcave.html#onlinew">well documented in the survey handbook</a>.
<p>
<p><b>Third</b>, and this is for when things seem to be going horribly wrong, look in the <em>scans</em> of the logbook, the bierbook and the callout book in e.g. in <a href="http://expo.survex.com/expofiles/writeups/2018/"><b>expofiles/writeups/2018</b></a> to find any record of trips which are otherwise unrecorded or lost and who was actually on expo on any one day. If even the scans don't exist then there is quite a bit of work to do before you can get on with the survey generation.
<hr />

41
handbook/treasurer.html
View File

@@ -112,7 +112,7 @@
Hassle everybody else too :-)</P>
<p>See the instructions to expoers on what <a href="/paperwork.html">their paperwork responsibilities</a> are as this sets out payment terms and says in writing that someone is only registered as coming on the expo <em>after</em> thier deposit has been recieved. It says "If you are late paying the deposit you may need to pay your entire expected cost, not just the deposit, before you can attend. The expo treasurer will tell you what is required". This was because we had one person just turn up without warning. (He was happy to pay, he just wasn't aware of the procedures.)
<P>A good way to get the deposits is with the Expo form. This is completed by each person wanting to go on the Expo. Have a look at past year's forms. The forms get you, as treasurer, (hopefully) all the information you'll need to start organising Expo. People are often pretty lousy at completing or even starting their forms, but you'll need an idea of when people want to go on Expo and a list of contact addresses etc. Distribute the forms:</P>
<P>A good way to get the deposits is with the Expo form. This is completed in some way by each person wanting to go on the Expo. Have a look at past year's forms. The forms get you, as treasurer, (hopefully) all the information you'll need to start organising Expo. People are often pretty lousy at completing or even starting their forms, but you'll need an idea of when people want to go on Expo and a list of contact addresses etc. Distribute the forms:</P>
<UL>
<LI>By email - <a href="onlinework.html">the expo mailing list</a> </LI>
@@ -127,10 +127,12 @@
<LI>Anything else you can think of. </LI>
</UL>
<P>There was an <a href="http://expo.survex.com/signup/submit.php">on-line version of the form</a> in 2014, and possibly even a script for processing the responses. Find a suitable nerd to fix it; it's not difficult. The web form can be completed on-line or printed out and sent to you.</P>
<P>There was an <a href="http://expo.survex.com/signup/submit.php">on-line version of the form</a> in 2014, and possibly even a script for processing
the responses. Find a suitable nerd to fix it; it's not difficult. Or use some newer online service, but not a Facebook "Event" as some
expoers are not <em>and will not</em> have Facebook accounts.</P>
<P>In the past requirements set by the GPF/NCA meant that <EM>all</EM> Expo members needed to be members of a club/organisation which is in turn a member of the NCA in order for Expo to get any grant money. ICheck whether this is still true.</P>
<P>In the past requirements set by the GPF/NCA meant that <EM>all</EM> Expo members needed to be members of a club/organisation which is in turn a member of the NCA in order for Expo to get any grant money. Check whether this is still true for the year you are treasurer.</P>
<!-- This doesn't need saying does it.
<H4 id="equipment">Equipment</H4>
@@ -152,15 +154,11 @@
<P>The Expo account is with National Westminster, number 22997253, sort code 60-04-23 (Market Street branch). Remember to give the bank the signature authority forms to authorise your successor before you leave Cambridge.</P>
<H4>The Expo Bier Bookand Sesh Book</H4>
<P>The <a href="bierbook.html">Expo Bier Book and Sesh Book</a> is a record of every expedition expenditure and many administrative details of Expo. Refined over many years, the format now consists of the following sections:</P>
<p>The expenses and sesh swaps are also copied online into the <a href="bankofexpo.html">bank of expo</a> and the bier book and sesh book are annotated when when an expense has been transcribed.
<p>The expenses and sesh swaps are also copied online into the <a href="bankofexpo.html">Bank of Expo</a> and the bier book and sesh book are annotated when when an expense has been transcribed.
<p>The 2016 expo bierbook and seshbook were scanned and can be downloaded (13MB and 5 MB) from here:
<a href="http://expo.survex.com/expofiles/writeups/2016/">expofiles/writeups/2016/</a>
@@ -200,7 +198,14 @@
<P>The Stamps page could be improved; I recommend Expo buys part of a sheet of stamps (with the edge pieces) and sticks the edge to the inside edge of a page in the bier book. Then have a stamp tally nearby.</P>
-->
<P>Anything else financial can also be included, particularly notes to the treasurer. The Bier Book, Sesh Book, Logbook, Callout Books and Survey Wallets file together make the original source documentation for each Expo.</P>
<P>Anything else financial can also be included, particularly notes to the treasurer. The <ul>
<li>Bier Book,
<li>Sesh Book,
<li>Logbook,
<li>Callout Books (basecamp and topcamp) and
<li>Survey Wallets lever-arch file
</ul>
together make the original source documentation for each Expo.</P>
<H4>The Gasthof Payment</H4>
@@ -210,11 +215,17 @@
<H4>Produce the Expo Bills</H4>
<P>The <a href="bierbook.html">Bier Book and Sesh Book</a>, as copied into the Bank of Expo, should be a complete picture of all Expo financial transactions.
<P>The <a href="bierbook.html">Bier Book and Sesh Book</a>, including pre-expo transactions andd all as copied into the <a href="bankofexpo.html">Bank of Expo</a>, should be a complete picture of all Expo financial transactions except for expo gear transport. As people leave expo enter their Gasthof camping nights in the Bank of Expo as a cost to them.
<P>You'll receive some Bier Book & Sesh Book entries by email, post and word of mouth after Expo, as people's credit card bills come in. Set a deadline (say, 40 days after the end of Expo) and add all entries to the Bank of Expo. Include all the other relevant transactions on the other Expo accounts.</P>
<p>After Expo, when you know who has contributed to transporting expo gear to and from Austria, create appropriate transactions in the <a href="bankofexpo.html">Bank of Expo</a> as shared expenses: for everyone flat-rate (gear transport), for everyone pro-rata (basecamp food and topcamp food). You can do this immediately after expo as you don't need to wait for sundry expenses to come in, so long as you have the Bier Book record of where people were and when.
<P>You'll receive some extra Bier Book & Sesh Book entries by email, post and word of mouth after Expo, as people's credit card bills come in. Set a deadline (say, 40 days after the end of Expo) and add all entries to the Bank of Expo.</P>
<p>You may need to create a little calculator work to get the total topcamp food bill and basecamp food bill, but you don't need to do any allocation to people: that is all done in <a href="bankofexpo.html">Bank of Expo</a> by putting the individuals' days in the allocation entries. So you do need to read and understand the <a href="bankofexpo.html">Bank of Expo</a> documentation. But it is a whole lot easier than creating as spreadsheet (last done in <a href="../expofiles/accounts/accounts2014.xlsx">2014</a>).
<!--
<P>Once all the various expenses have been entered in the Bank of Expo (it's probably September/October by now), you're ready to tackle the spreadsheet. Here is the <a href="../expofiles/accounts/accounts2014.xlsx">2014 Expo spreadsheet</a> - but this predates Bank of Expo, so hassle a more recent treasurer to get the latest copy. You don't have to use the spreadsheet, but it's best to unless you're a database wizard. Basically you remove the sheets for last years members, copy new blank pages for this year's members and then add this year's data. It's fairly straightforward, but lengthy and requires concentration.</P>
-->
<!--
<P>All expenditures in the Bier Book will fall into one of the categories:</P>
@@ -230,9 +241,9 @@
</UL>
-->
<P>What is paid for is determined by the principles described in part 1 of this document. Once all the data has been entered, check that each person has been allocated appropriate <EM>traveller</EM>, <EM>caver</EM> and <EM>grantshare</EM> values in the spreadsheet.</P>
<P>What is paid for, for transporting gear, is determined by the principles described in part 1 of this document.
<!--Once all the data has been entered, check that each person has been allocated appropriate <EM>traveller</EM>, <EM>caver</EM> and <EM>grantshare</EM> values in the spreadsheet.</P>
-->
<P>When sending out the Expo bills, include the addresses of the creditors. Send individual emails personally to each member, rather that announcing it on communal emails. This reduces the amount of ranting about 'Why's my bill more than his?'. However, if anyone asks, have the relevant data ready.</P>
@@ -255,7 +266,7 @@
<!--
<P>Finally, keep these files up-to-date, and stored both on the Expo accounting disk and the CUCC file space on the PWF. Wookey or Olly may also be able to arrange archive space.</P>
-->
<p>Archive all the accounts on the Expo online systems in expofiles/accounts and keep scanned copies of the Bier Book and Sesh Book in expofiles/writeups/<year>/ (along with the scanned copies of the logbook and the callout books). See 2018 for a nearly complete set: <a href="../expofiles/writeups/2018/bierbook/">expofiles/writeups/2018/bierbook/</a>.
<p>Archive all the accounts on the Expo online systems in expofiles/accounts/&laquo;year&raquo;/ and keep scanned copies of the Bier Book and Sesh Book in expofiles/writeups/&laquo;year&raquo;/ (along with the scanned copies of the logbook and the callout books). See 2018 for a nearly complete set: <a href="../expofiles/writeups/2018/bierbook/">expofiles/writeups/2018/bierbook/</a>.
<H3>Committees...</H3>