If you want to roll up your sleves and fix some horrifying annoyance that is bugging the hell out of you then you have come to the right place.
and you will have dismissed them as too trivial for your needs. You will have skipped over all that nasty confusing Django stuff:
You want to dive into the real stuff and add missing fields to the core data model:
We admire your drive and enthusiasm. We were like you once.
First, you need to get the "expoadmin" password from a nerd. Then you will be able to dive into the online admin system where you can explore and poke the live system and database using the system admin control panel. This has a data structure browser for the classes and fields of the system as live and in-use: all the foreign keys and relationship cardinalities. (This is not the same thing as the troggle control panel which is for deeper data management: bulk uploading and export of data files.)
And, you may be surprised to discover, we have given a lot of thought into how to make it easier for you to get involved in the programming while not screwing up this multi-decade software project.
Everyone at some point feels like giving up and wonders if we should just rewrite it all from scratch using 'modern' techniques. Several of us have given this a lot of thought, see 'A kinder, simpler troggle', the 2030 plan, architecture constraints and most importantly, the 4-layer stack any future technology with some public URLs would need to emulate.
We have also been learning from the global software community when you really do need to 'Kill it with Fire': what are the characteristics of code and of organisations that mean that it is a good idea to give up, and if so how to manage the rewrite. The answers are "almost never" and "don't": as explained in this summary of the book 'Kill it with Fire'.
Replacing old systems, and changing their architecture, while keeping them operating continuously, is now a well-understood software engineering process comprising a dozen separate techniques. With troggle, we can probably fairly easily replace the cross-referencing between different types of things (e.g. logbook entries, survex files, persons, expedition days) but we will find it tricky to replace the sychronisation and concurrency that SQL databases give us 'for free'. We are waiting to see if Django comes up with something cunning as it steadily converts to a more asynchronous architecture using python asyncio.
Perhaps you can program something external to troggle, in JavaScript say, using troggle data?
It's a simple sequence which steadily builds your expertise:
This happens all the time. If ever troggle is crashing on you very mysteriously, it is almost certainly due to a typo in troggle/urls.py . Odd but true.
[Note that /survey_scans/ is a url published by troggle and is not the same thing as the real directory /expofiles/surveyscans/ at all.]
Only a small part of troggle's original plan was fully implemented and deployed. Many of the things it was intended to replace are still operating as a motley collection written by many different people in several languages (but mostly perl and python; we won't talk about the person who likes to use OCamL).
Since 2008 we have been keeping detailed records of all data management system updates in the version control system. Before then we manually maintained a list of updates which are now only of historical interest.
A history of the expo website and software was published in Cambridge Underground 1996. A copy of this article Taking Expo Bullshit into the 21st Century is archived here.