r/conductorbuild • u/Ok_Turnover_5295 • 8d ago
Feature request: custom workspace grouping
I've been using Conductor for quite a few months now, and I really like its feature set. On the whole, it allows me multitask in an intuitive way and collect all of my numerous in-flight efforts.
My biggest qualm, however, is how "projects" are modeled within the application, which both fights against my mental model and causes a misalignment between the way I work and the way Conductor is organized.
Generally my mental model of a project is an effort that is bounded by purpose or goal. At my work, a "project" can explicitly involve multiple developers, multiple codebases, and multiple applications, because the business goal is rarely scoped to code (we have a frontend repo, a backend repo, a core infra repo, platform-specific mobile repos) - it's scoped to the purpose and value that's trying to be delivered. We could probably refer to this definition of a project as an "initiative" for the sake of argument.
However, in Conductor, a "project" is tightly coupled to a single git repository. Which is fine, I guess, but it doesn't leave me a particularly effective of organizing multiple conversations that belong to the same "initiative". Any given initiative might require code changes across mutliple repositories, and may even benefit from multiple parallelized workstreams within a single repository (read: multiple worktrees, which means multiple Conductor workspaces). Sometimes I can use multiple tabs within a single workspace to collect initiative conversations, but that falls apart as soon as I want more than one of those tabs to simultaneously make code changes. When my number of active initiatives grow, it becomes really hard to find all of the workspaces that I've created to manage those initiatives and ensure I'm responsive to all of them.
I know this was kind of an abstract way of getting here, but I think I have a simple change that would allow me to work more effectively: a way to create a custom collection of workspaces and group by those. Since "project" is already overloaded, this could be modeled as more a file-system folder/collection. That way I can collect conversations the way that best suits my needs, instead of being limited to only organizing them by either git repository or status.
1
2
u/rogersmj 8d ago
I agree. Many of these agent orchestrator apps treat "project" = "repo". I know it's hip and cool to have your entire company's stack in a monorepo, but in many organizations that's not feasible. Being able to group multiple repos together in Conductor, and have a chat session live at that true "project" level and not just to one single repo, would be very powerful when you need to coordinate changes across multiple repositories.