More and more developers are realizing they have real collective power, and the tech worker movement is growing because of it. We’re on the front lines of everything from pushing for ethical AI to just getting better working conditions, and that’s shaping the industry’s future. But if you’re a developer in the middle of this, how do you actually document what’s happening so the story sticks and the impact is preserved?
Key Takeaways
- You need a documentation strategy from the jump. Decide on tools like Git for version control and pick a CMS for getting the word out.
- Stick with open-source static site generators like Jekyll or Hugo. They’re cheap to run and easy to maintain, which is what you need for an archive that has to last.
- Get serious about metadata using Dublin Core standards. It’s the only way people will find your stuff years from now and trust that the archive is complete.
- When you’re documenting people’s stories or sensitive unionizing efforts, ethical data collection and getting consent aren’t optional, they’re the first priority.
- Look for help from academic institutions. A group like MIT’s Program in Science, Technology, and Society could be a partner in preserving this digital history.
1. Define Your Documentation Scope and Goals
First thing’s first: before you write any code or hit record on an interview, you’ve got to decide what slice of the tech worker movement you’re documenting and why it matters. Are you zeroing in on a single labor dispute, the mess of ethical problems in AI development, or just the big-picture trends in tech organizing? For example, if you’re covering the push for responsible AI, you’re not just collecting feelings, you’re tracking policy proposals, public statements from the big tech firms, and developer-led projects. I’ve learned the hard way that a tightly defined scope is the only thing that saves you from scope creep and keeps your work focused.
You also have to know who you’re writing for. Is this an internal resource for organizers, a record for future historians, or something for the general public? The answer changes your tone, how deep you go, and what platforms you use. If you’re building a historical archive, you need a detailed, almost academic approach with tons of primary sources. If you just want to raise public awareness, you’ll probably lean more on easy-to-read stories and multimedia. It’s worth looking at how serious institutions handle this. The Massachusetts Institute of Technology (MIT) Libraries, for example, have published their digital preservation guidelines, and they hammer on the importance of long-term accessibility. That’s not just a nice-to-have for a project like this.
Pro Tip: Write a one-sentence mission statement. For example: “To create an accessible, verifiable archive of developer-led initiatives advocating for ethical AI development in the Bay Area from 2024 to 2026.” A sentence like that will keep you from getting lost in the weeds.
Common Mistake: Trying to boil the ocean by documenting everything. You’ll just drown in data, the quality will be all over the place, and you’ll end up with a record that feels incomplete anyway. You have to focus.
2. Establish a Strong Version Control System for Data and Code
We all use version control for code, so just apply that same discipline to your documentation. You absolutely need a system like Git. It’s perfect for tracking changes not just in code but in your text files, data sets, and even the metadata for your media files. Think about it: if you’re building a timeline of events, every single update, every correction, every new entry needs to be its own commit with a descriptive message.
Here’s a basic workflow using Git and a remote repository service like GitHub:
- Initialize your repository: Navigate to your project directory in the terminal and run
git init. - Create a
.gitignorefile: Exclude sensitive information or large binary files that shouldn’t be version-controlled directly. For example, add*.DS_Store,/node_modules/, or any directory containing raw interview audio. - Commit regularly: After making meaningful changes to your documentation (e.g., adding a new interview transcript, updating an event description), stage your changes with
git add .and commit withgit commit -m "Added transcript for [Interviewee Name] on [Date]". - Push to a remote: Regularly push your local commits to a remote repository using
git push origin main. This provides a backup and facilitates collaboration if you’re working with a team.
If you find yourself dealing with big, complex datasets, you should probably look at using DVC (Data Version Control) on top of Git. DVC is built to handle large files and even ML models, which might be exactly what you need if your project involves analyzing data trends or tracking how a company’s AI models change over time.
Screenshot Description: A terminal window showing the output of git log, oneline, displaying a series of concise commit messages related to documentation updates, such as “feat: add initial draft of ethical AI policy demands” and “fix: correct date for 2025 tech workers’ solidarity rally.”
3. Choose the Right Tools for Content Creation and Management
The tools you pick will make or break your workflow and decide whether your archive even survives. For anything text-based, Markdown is the obvious choice. It’s light, you can read it raw, and it converts to anything. Just write in an editor you already know, like VS Code with a live preview extension.
When it’s time to publish, a static site generator (SSG) is almost always a better bet than a full-blown dynamic CMS for this kind of archival work. Tools like Jekyll or the much faster Hugo spit out simple HTML, CSS, and JS files. That means the site is portable, more secure, and barely needs any server resources, a huge deal if you have no budget and need the site to stay online for decades with zero maintenance. I’ve seen so many good archives just vanish because they were built on some complicated CMS that no one knew how to update anymore.
Example Jekyll setup for a “Movement Archive”:
_config.yml
_posts/ 2026-01-15-ethical-ai-manifesto.md 2026-02-20-interview-sarah-developer.md
_pages/ about.md timeline.md
_data/ events.yml organizations.yml
_includes/
_layouts/ post.html page.html
assets/ css/ images/
This kind of structure gives you a clean separation of concerns. You just drop your articles and interview transcripts as markdown files into `_posts/`, build out your static “About” page in `_pages/`, and handle structured data like event timelines or lists of organizations in simple YAML files inside `_data/`. It makes the whole thing easy to manage and, more importantly, easy to version with Git.
4. Implement Strong Metadata and Archival Standards
An archive is useless if no one can find anything in it a few years down the road. That’s what metadata is for, and you have to be disciplined about it. For every single piece of content, every interview, press release, or even a code snippet from a protest tool, you need to log the basics:
- Title: Make it clear and descriptive.
- Creator/Author: Who actually created this?
- Date Created/Published: When was this recorded or made public?
- Keywords/Tags: Use terms people would actually search for (e.g., “AI ethics,” “labor organizing,” “developer advocacy,” “MIT”).
- Description/Abstract: Write a quick summary of what’s in the file.
- Source: Where did you get this? Was it a “Personal interview,” an “Official company statement,” or a “Public GitHub repository”?
- Rights/License: How can other people use this? Specify a license like Creative Commons BY-NC-SA 4.0.
You should seriously consider adopting a formal metadata standard like Dublin Core. I know it sounds like overkill for a small project, but using standardized fields is what makes your archive compatible with larger library and archival systems down the line. For instance, Dublin Core forces you to use the ISO 8601 format (YYYY-MM-DD) for dates, which means there’s zero ambiguity about `01-02-03` ever again.
And don’t just keep metadata in a separate spreadsheet. You need to embed it directly into the files themselves whenever you can. That means using EXIF data for images and ID3 tags for audio files. A command-line tool like ExifTool can script this and save you a ton of time. If your files ever get separated from your main archive, this is the only way the context travels with them.
Pro Tip: Write a schema for your metadata. It’s just a simple document that defines all the fields you’re tracking, the format you expect for each (e.g., date format), and some examples. If you have any collaborators, this is non-negotiable for keeping the data consistent.
5. Ethical Considerations for Data Collection and Privacy
Documenting a worker’s rights movement comes with huge ethical responsibilities. Your first job is to protect the privacy and safety of the people involved. You must get informed consent before you even think about recording an interview or publishing a personal story with identifiable details. Be totally transparent: tell them exactly how their information will be used, where it will be stored, and who will have access to it.
You’ll need to use anonymization and pseudonyms, especially with sensitive data. If you’re documenting something like a specific case of workplace retaliation, you have to be 100% sure that person can’t be identified unless they’ve given you explicit consent and you’ve walked them through the risks. Go through all your data and scrub any personally identifiable information (PII) that might have slipped in and could get someone in trouble.
Think about the long-term consequences of what you publish. Could something you put online today be used to hurt someone five years from now? This is a very real risk, I’ve seen it happen where public information from organizing efforts gets weaponized later. You need a data retention policy that spells out how long you’ll keep things, and more importantly, a plan to securely delete data if it’s no longer needed or if someone revokes their consent.
For a concrete example, if you’re archiving old email threads or Slack logs from an organizing committee, you’ll almost certainly need to redact names, email addresses, and company-specific jargon to protect people. You can use tools like Blender for blurring faces in video or GIMP for redacting parts of images. For text transcripts, a simple text editor and a careful eye are your best tools.
6. Collaborate and Seek Institutional Support
Don’t try to document the whole tech worker movement by yourself. Working with other people makes the project stronger by bringing in different perspectives and sharing the load. Find other developers, researchers, or even professional archivists who are thinking about the same things.
It’s also worth reaching out to academic institutions. A department like MIT’s Program in Science, Technology, and Society (STS) or a university library will have people who are experts in digital humanities, archival science, and oral history. They can give you advice, maybe get you access to resources, and could even agree to be the long-term home for your archive. A partnership like that gives your project instant credibility and a real shot at permanence.
Take the MIT Libraries Institute Archives, for example, they are actively collecting materials on the history of science and tech. If you show up with a well-organized, ethically sourced archive of the tech worker movement, you have a good chance of starting a conversation about getting it included in their collections. That’s how you make sure it’s preserved for future researchers and activists. Getting that kind of institutional support is probably the single best thing you can do for the project’s long-term survival and impact.
Common Mistake: Working completely alone. When you operate in a silo without anyone else looking at your work, the project can get weirdly insular, miss huge perspectives, and in the end just won’t be strong enough to have a lasting impact.
As a developer, you have the technical skills to do more than just build products, you can use them to document the tech worker movement, preserving its history and helping build a better future. If you apply real discipline to your version control, choose your content tools wisely, handle data ethically, and work with others, you can create a resource that will be essential for anyone trying to understand the intersection of technology and labor for years to come.
What are the best platforms for publicly sharing documentation of the tech worker movement?
Your best bet is a static site generator like Jekyll or Hugo, hosted on something like GitHub Pages or Netlify. It’s reliable, secure, and cheap (or free). Because they just generate plain HTML files, the sites are fast, easy to access, and much less likely to break or become obsolete over time.
How can I ensure the long-term preservation of digital documentation?
For long-term preservation, you have to use open, non-proprietary file formats (like Markdown, plain text, JPEG, WAV). You also need to use a real metadata standard like Dublin Core, keep multiple backups in different physical and cloud locations, and, ideally, find an institutional partner like a university library that does digital preservation professionally.
What ethical guidelines should I follow when interviewing tech workers for documentation?
Rule one is get informed consent. Before you record, explain exactly how their interview will be used and stored. Always offer them the option to be anonymous or use a pseudonym. You have a duty to protect their sensitive personal information, and you must respect their right to change their mind and withdraw consent later. Their safety and privacy are more important than your project.
Can I use AI tools to help document the tech worker movement?
Sure, AI can be a useful assistant for things like getting a first-pass transcription of an audio interview or summarizing a long document. But you have to be extremely careful. Always have a human review and fact-check anything the AI produces. And think very hard about the privacy implications before you upload sensitive interview data to a third-party AI service. You are still responsible for the accuracy and ethics.
How can developers contribute to the tech worker movement beyond documentation?
Documentation is just one piece. You can build tools that help organizers communicate securely. You can push for ethical code reviews in your own company. You can advocate for responsible AI, join or help form a union, contribute to open-source projects that support workers, or use your expertise to explain the real-world impact of technology to people who need to know.
