@adrianlu thank you for including me, yes indeed, I am very interested in this topic.
@gordonb to your list, if you want people to get into the details, hack it and develop new features, I would add a key element: technical architecture of the solution (at least, a high level description or overview).
Let me share my recent experience: one week ago, I decided to create a database (sqlite3) to store the status of the actuators and the points of the sensors every X time (let's say, every 10 minutes), so then I can play with this data. Although I am not an expert in Python and OOP, past days I spent some time surfing the different pieces of code (grodaemon, server, bot, communications, actuator, element, sensingpoint, ...) and I understand many things, but I am missing a few ones that are relevant, and don't understand others (for example, there are two logs - grodaemon and grostatus - that my FC is not using) and in the absence of an architecture overview, I do some trial and error, and so far, it's been error (I did something that the UI can't read the values of the sensors anymore, so I had to flash again the image and reinstall the SD card). This was not a big deal but I lost time.
BTW, funny comments in your code (I did exactly the same when I developed software in the 90s). Again, happy to help.