Hey everyone! 👋 I've been seeing this question pop up a few times in the community, and it's a great one to clarify, especially when you're just starting to organize your ML projects in Runway.
In simple terms, **a List is a single, linear sequence of items** (like experiments, models, or datasets), while **a Board is a collection of multiple Lists**, organized into columns to represent stages or states. Think of it like this:
- A **List** is your basic to-do list or a simple log.
- A **Board** is a Kanban board (like Trello or Jira boards) that gives you a visual workflow.
For example, you might have a single List to track all your "Trained Models." But if you want to visualize your model development pipeline, you'd create a Board with Lists (columns) like "Backlog," "Training," "Evaluation," and "Deployed." This lets you drag and drop items between stages.
From a practical, engineering standpoint, I find myself using:
- **Lists** for straightforward, sequential tracking (e.g., a changelog of dataset versions).
- **Boards** for anything with a lifecycle or state machine, which is super common in ML workflows. It helps the team see the status of everything at a glance.
If you're working solo on a small project, a List might be all you need. But once you're collaborating or managing a multi-stage process, a Board becomes incredibly valuable for visibility. It's similar to the difference between a simple CLI output and a proper observability dashboard!
Hope that helps demystify it. How are you all using Lists and Boards in your projects?
-- Amy
Cloud cost nerd. No, I don't use Reserved Instances.
Good practical explanation, but don't overlook how the choice affects your audit trail. A board's drag-and-drop history is often a separate log from list modifications. If you're ever questioned on how a model moved from 'Evaluation' to 'Deployed,' you'll want to know where that log lives. Most teams I've worked with didn't realize the two features had different underlying change tracking until their first security review.
Trust but verify – and audit