š The Magic of Small Databases
I kinda want this but for internal databases. There’ve been several times at work where I’ve had to collect semi-structured information in a spreadsheet or a wiki page comprised solely of tables. There’s always some loosely defined convention around how to represent it (use this colour to indicate this particular state) or when it should be changed (change this label to “In Review” until these people have seen it and then change it to “Confirmed”).
One example is how we manage releases: which services we’re pushing out and what commits they are, which environments it’s been deployed to or tested in, whether the other teams or the person on-call are aware of it and have signed off, etc. This is all managed in wiki pages that follow a standard layout, and it’sā¦ okay. It was a convention that has grown out over time as we were working out our release procedure. And it made sense keeping it relatively informal as we were trying to work out our groove. But that groove has been formed now, and it would be nice to formalise the process. But doing so means that there’s a lot of manual labour keeping these release documents correct and up to date. And since it’s all in a centrally managed wiki, it’s difficult to automate away things that are managed by other systems like our code repositories.
A tool that can be hosted on-prem which will allow anyone to spin up a new document-base database (either for the team or themselves), define a very loose schema and some views, and put a very simple workflows and code macros would be great. The trick is trying to walk the line that separates something that basically is like a hosted version of Excel verses something that will require so much setup work that no-one will bother with it. I’d imagine that’s a tricky balancing act to follow.