Shared projects and roles in W&B are the system’s way of letting multiple people work on the same experiments without stepping on each other’s toes or creating duplicate runs.
Here’s how it looks when it’s actually working. Imagine you’re training a new image segmentation model. Your colleague, Alice, has already set up a W&B project called awesome-segmentation and invited you.
import wandb
# Alice's setup (you're joining this)
# project = "awesome-segmentation"
# entity = "your-team-name"
# Your code to log runs to her project
run = wandb.init(project="awesome-segmentation", entity="your-team-name", job_type="training")
# Log some metrics
run.log({"loss": 0.5, "accuracy": 0.8})
run.log({"loss": 0.4, "accuracy": 0.85})
run.finish()
When you run this, your training job appears right alongside any other runs Alice or other team members have logged to awesome-segmentation. You can see their runs, and they can see yours, all in one place.
The core problem W&B collaboration solves is avoiding the chaos of scattered experiment data. Without shared projects, you’d end up with multiple copies of the same project, each with different runs, making it impossible to get a unified view of model performance. Roles then provide granular control over who can do what within these shared spaces.
Internally, W&B uses a hierarchical structure: entity (your team or individual account) > project > run. When you wandb.init with a specific project and entity, you’re telling W&B to associate that run with that specific project under that entity. Access control is then managed at the project level, allowing owners to assign roles to other users or teams.
The primary roles are Admin, Member, and Viewer. An Admin can manage project settings, invite/remove users, and delete the project. A Member can log runs, create new runs within the project, and view all runs. A Viewer can only see runs and project data but cannot make any changes or log new runs. When you’re invited to a project, you’re typically given a Member role, granting you the ability to contribute your experiment results.
When you’re working within a shared project, you can see the runs logged by others. For example, if Alice logged a run with config={"learning_rate": 0.001}, you’ll see that config parameter listed on her run’s page. You can then use this information to inform your own experiments. If you have Admin privileges, you can navigate to the project’s settings page within the W&B UI, find the "Members" or "Collaborators" section, and invite new users by their W&B username or email, assigning them a role.
The most surprising thing is that W&B doesn’t enforce strict isolation between runs within a shared project by default. While each run has its own unique ID and data, the project acts as a flat namespace for all runs associated with it. This means that if you accidentally log a run with the same name as someone else’s, W&B will simply append a number to yours (e.g., my-run-2) to ensure uniqueness, but the project itself doesn’t automatically group runs by user or by feature branch. You have to rely on job_type, tags, or custom config parameters to organize your work within the project.
The next challenge is understanding how W&B’s system handles artifact versioning across multiple contributors and projects.