How do you organize technical resources for a long-term project?

Question

I'm curious how other people organize information when working on a project that involves lots of different technical resources.

For example, with a retro gaming or emulation project, you may need to keep track of emulator information, compatibility notes, configuration settings, game information, troubleshooting solutions, and other reference material. After collecting a lot of information, it can become difficult to remember where everything is.

I've been looking at different ways to keep these resources organized so I can quickly find useful information later. Airtable seems interesting for this because information can be grouped and filtered instead of just being kept in a long list of bookmarks.

One example of the type of technical reference I keep coming back to is:

https://ps2biosonline.com/

I'd be interested to hear how other Airtable users organize research or reference material for their own projects. Do you use separate tables, tags, linked records, or another system?

Nick_Gatens · Answer

Last year, I worked with 200+ people to transition/combine/consolidate 45-ish Google Sheets into 8 Airtable bases. Massive undertaking, so we needed something that’s in the same realm. For us, it ended up as a Resources table where each record represented one of the Google Sheets we were transitioning. These held things like notes/attachments/direct URLs to the sheets, and each record was named after the Google Sheet. These Resource records were then linked to various other tables. For example, a Staff table which allowed us to see which teams/individuals used which Google Sheets. And we even went so far as to list individual Google Sheet columns as rows/records in a Columns table and linked those back to the Resources as well. This allowed us to see which columns each Google Sheet had in common, who was responsible for updating which column, and whether or not we had the opportunity to consolidate, remove, or rethink specific columns.

In your example of emulation, maybe you start with an Emulator table, where each record represents an instance of an emulator. You could attach .zip files for that emulator, or .pdfs/readme files so those references live in the emulator record itself. The Emulator table could then be linked to multiple other tables – maybe a Console table for example, where you could then roll up available emulators linked to a given console (and click in to see those resources from the Console side of the linked record.) And maybe then your emulator records in the Emulator table could be grouped / filtered / viewed by which console they’re linked to from the Emulator side of the linked record. Or perhaps you have a Games table where each record represents an individual game, and each game is linked to Emulator records from the Emulator table. Potentially with multiple linked records fields - say one for Compatible Emulators and one for Incompatible Emulators. So you could filter/view/group your games by Compatible Emulators, or see which games are compatible from within your Emulator table.

The options are almost endless, so there’s not really a one size fits all solution! Much of what you end up building depends heavily on both the data you’re working with, how that data relates to itself, and what you want to be able to do with that data. But that’s also why it’s often such a powerful tool for these kinds of projects!

Sign up

Login with SSO

Login to the community

Login with SSO