Multica / Workspaces and Teams

Project

Group related issues into a group and follow them as a unit - with priority, status, progress and person in charge.

Overview

Projects in Multica are containers for related issues. Use it when a piece of work is larger than a single issue but smaller than the entire workspace - a release, a migration, a feature that is divided into multiple parts, a research that will unravel multiple leads.

Each project has a name, icon, description, responsible person (lead, which can be a member or agent), status (planned / in_progress / paused / completed / cancelled), priority (urgent / high / medium / low / none), and an associated issue The progress percentage automatically calculated by the status.

The relationship between projects and issues

Projects and issues are independent objects with a many-to-one relationship: one issue belongs to at most one project; one project can accommodate any number of issues. Linking and unlinking can be reversed at any time - dragging in the Kanban view, or using the project selector in the properties panel on the right side of the issue.

The progress bar of the project is automatically calculated based on the status of the associated issue - the more issues are done, the fuller the progress bar will be. cancelled issues are not included in the denominator; backlog issues are included in the denominator but not the numerator.

associated resources

Each project has a Resources area that can be linked to a GitHub repository. After being mounted, agents assigned to issues in this project can read and write these repositories when executing tasks - Multica will pass the repository URL as a context to the daemon process.

Resources are at the project level; multiple projects must share the same repository and must be mounted separately.

Delete project

Deleting a project does not delete its issues. The associated issue is simply disassociated and returned to the flat issue list in the workspace. This is intentional - even if the framework of the project itself changes, the work within is usually not a one-off.

If you really want to delete the work, archive or delete the issue first, and then delete the project.

Project leader

The leader is the person — or agent — who has overall responsibility for the project. This is a soft signal, not a permission control: any member of the workspace can edit the project, regardless of who is responsible. The project leader can be:

Members (people) in the workspace
Agent - Suitable when most of the work in the project is to be handed over to agents (for example, "weekly bug inspection" is led by an inspection agent)

Next step