All Posts

Collaborate in Projects

Invite collaborators, set roles, and co-build chats + artifacts (with citations) inside Open Paper Projects.

Research rarely happens alone.

A good literature review is a team sport: someone is collecting PDFs, someone is sanity-checking claims, someone is extracting key numbers, and someone is trying to turn it all into a coherent narrative.

That’s why Projects in Open Paper aren’t just a way to bundle papers—they’re a shared workspace you can invite others into. If you haven’t tried Projects yet, start with the announcement post: Projects: Your Research Hub.

Quick walkthrough (video)

This segment covers Projects (2:14–3:40). Prefer the full video? Watch it on YouTube: xBwzPyMO8ZM.

What “collaboration” means in an OP Project

When you collaborate inside a Project, you’re collaborating on the whole workflow:

• A shared set of papers (uploaded or added from your library)
• Shared project chats (with grounded citations)
• Shared artifacts like Audio Overviews and Data Tables
• Lightweight coordination via roles and ownership

Instead of passing around PDFs and half-finished notes, your team can work in the same place—and keep the evidence trail intact.

Roles: keep the workspace open, without losing control

Every Project collaborator has a role. Roles are designed to match how research teams actually operate: a small set of people who build and edit, and a wider set of people who review.

Attribute	Viewer	Editor
Best for	Advisors, stakeholders, “review-only” teammates	Active contributors
Can	Read everything in the Project (papers, chats, artifacts)	Add papers Start new project chats Create artifacts (e.g., Audio Overviews, Data Tables)
Cannot	Create new chats Add papers Create artifacts	—

Note: the Project creator is the only admin. They can invite collaborators, change roles, and manage access over time.

How to invite collaborators (and why it’s faster than “just forwarding PDFs”)

Inviting someone is intentionally lightweight:

1. Go to your Projects and open the Project you want to share.
2. In the top-right, click Invite.
3. Enter one or more emails and choose Viewer or Editor.
4. Send the invite.

If your collaborator doesn’t already have an Open Paper account, they’ll be prompted to create one first—then they can accept the Project invitation.

While the invite is still pending, it shows up as a pending invite in your collaborator list, so you can track what’s outstanding (and retract it if you need to).

How your teammate accepts an invite

On the collaborator side:

1. Go to the Projects page.
2. Click the mail icon to view pending invitations.
3. Accept (or reject) the invite.

Once accepted, the Project will appear in their Projects list like any other.

Working together: a few collaboration patterns that actually work

Here are a few patterns we’ve seen work well for real teams.

Pattern 1: “Two-pass” literature review (Editor + Viewer)

• An Editor builds the Project: uploads papers, starts the first couple of chats.
• A Viewer reads the chats and clicks through citations to verify claims.
• The Viewer leaves feedback out-of-band (Slack / email / meeting), while the Project remains the single source of truth.

This is a good fit when you want a fast first draft, but still want rigorous verification.

Pattern 2: Split extraction work (multiple Editors)

If you’re doing anything systematic—method comparisons, limitations tracking, outcome extraction—assign multiple Editors.

• Everyone adds papers they’re responsible for.
• Everyone runs focused chats against the same Project context.
• One person creates a Data Table to consolidate the extracted fields.

Data Tables are purpose-built for “evidence that travels” across papers. If you haven’t used them yet, see: Data Tables: From Reading to Writing.

Pattern 3: One Project, many conversations (with attribution)

When multiple people are in a Project, conversations become much easier to navigate because chats show who started them.

That means a Project can naturally evolve into:

• a “methods” thread
• a “limitations” thread
• a “background” thread
• a “write-up outline” thread

…and it’s still obvious who owns which thread.

Collaborators + artifacts: turning meetings into outputs

Collaboration gets dramatically easier when your shared workspace produces shared outputs.

Two artifact types are especially useful in a team:

• Audio Overviews: quick briefings to align before a meeting, or to catch up after. (More: Why Audio?)
• Data Tables: structured comparisons you can export, audit, and cite.

A simple workflow that works well:

1. Before a sync, create an Audio Overview so everyone has the same baseline.
2. During the sync, capture decisions as a new Project chat (“What did we agree on? What’s uncertain?”).
3. After the sync, generate a Data Table for the exact fields your write-up needs.

Managing access over time (without breaking the project)

Projects change as research evolves. A few tips:

• Start broad: invite more Viewers than you think you need.
• Keep Editors tight: give edit access to the people who will actively contribute.
• Use role changes rather than “new projects” when the core question stays the same.
• If someone is done contributing, remove them—your Project stays clean and focused.

What’s next

This is the first step toward richer collaboration in Open Paper. The goal is simple: better ways for humans to work with humans, without sacrificing citation integrity.

If you have a collaboration workflow you’d like OP to support—lab meetings, systematic reviews, policy memos—tell us what you’re trying to do, and what breaks today.

---

Ready to collaborate? Create a Project at /projects/create and invite your team.