I'm deep into organizing my ResearchRabbit library, but I'm getting a bit tangled between papers I've *actually read* and those I've just saved for later. It feels like a merge conflict in my reading queue! 😅
How do you all manage this state? I'm considering a naming convention for collections or tags, like `read::` vs `saved::`. Curious if anyone has a solid gitops-style workflow for this? Maybe something like a simple label in the notes field?
> git commit -m 'done'
git push and pray
I'm just starting to build my own research pipeline for a small fintech startup. We're all-remote and everyone self-manages their lit review, so I've been testing a few simple systems.
**Manual tagging overhead**: Every paper needs a manual tag on import. That's an extra 15 seconds each, and if your pipeline is like mine with 20+ papers a week, it starts to add up.
**State tracking in notes fields**: I tried using a `status: read` field in Zotero's notes. It's cheap (free tools), but you have to open each entry to see it, losing the at-a-glance view you get with dedicated tags or folders.
**Git-based versioning (your idea)**: I scripted a hack using a local git repo and markdown files. A `git log --oneline` shows "read" commits, but syncing that state back to ResearchRabbit or Zotero is a manual, error-prone step. It adds maybe 30 minutes of maintenance per week.
**Integrated workflow tools**: Something like Notion or Airtable can model this perfectly with a "Read?" checkbox column. However, that means moving your whole library out of a dedicated reference manager, and the import/export for citations becomes a new problem to solve.
I'd use a simple tag-based system inside your existing manager (like `#read` and `#toread`) for now. It's the lowest friction. If you want a cleaner gitops style, tell us your weekly volume and if you need to share this "read" status with a team, because that changes everything.
Tag naming works. I use `status_read` and `status_unread`. Prefix keeps them grouped.
Your gitops analogy is interesting but state management isn't linear. A paper can be partially read, re-read, or skimmed. A commit log only captures a single boolean transition.
If you're in ResearchRabbit, a custom field is better. You can filter on it directly. Tags are for categorization, not state.
Your tag naming idea seems straightforward. I'm trying something similar, but what do you do with papers you've only skimmed? That doesn't feel like "read" or "saved."
I'm also curious about the notes field approach. When you said a simple label, do you mean you'd write the status as the first line of the note? How do you quickly check that later without opening everything?
The git commit analogy is funny, but state management isn't version control. Your naming convention will break the moment you need a third state like "skimmed" or "in-progress."
If you're sticking with ResearchRabbit, use their custom fields. It's a dedicated column you can sort and filter, unlike tags which are for categories or notes you have to open. Tags like `read::` are just manual metadata with extra steps.
Define your states clearly first. Boolean `read` vs `unread` might be too simple, but adding too many becomes its own management problem.
cost optimization, not cost cutting
The gitops analogy is fun but it breaks down fast, like trying to use Salesforce for personal contacts.
I tried the tag naming thing in ResearchRabbit. `read::` and `saved::` looks neat until you realize you've also tagged things with `ml_models` and `2024_review`. Now your tag list is a mess of status and topic all mixed together, and filtering for "all saved papers about transformers" becomes weird.
What worked better for me was a dedicated custom field called `Reading Status`. Single-select dropdown: Saved, Skimmed, Read, In Progress. It's a column, not a tag, so you can sort the whole library view at a glance. It's the difference between Salesforce's Stage field and just using random tags on a contact.
A notes field label is invisible until you click in. Don't do that to future you.
Still looking for the perfect one
Your git commit line made me laugh, but the analogy is a bit too clean for the mess of actual reading. I see the appeal of a naming convention, but as others have noted, tags tend to blend topics and states into one hard-to-filter soup.
If you're committed to tags for some reason, consider a rigid prefix like `_state_` to force separation, e.g., `_state_read`, `_state_saved`. It's still manual, but at least it groups them away from your topic tags.
Keep it constructive.