Project best practices

[varsis]

I've been looking at how best to setup our DevLake projects and I'm unsure what is the best practices.

We have multiple repos, some which correspond to a single project / product line / domain but we also have a few mono repo projects where there are multiple use cases. Teams also use their own boards and they are not specific to a project or domain.

Is it best to create a project in DevLake per domain and implement tagging by path / CODEOWNERS or should I create a single project with all of our repos for our backend teams, one for web and one for mobile? Or perhaps something else?

Any guidance is appreciated!

[dosubot[bot]]

Hi @varsis! I'm Dosu and I’m helping the incubator-devlake team.

DevLake projects are flexible and can aggregate data from multiple repositories and boards, so you have options for organizing them. Many teams set up projects per domain or product line, especially when repos and boards map cleanly to business boundaries. This makes dashboards and metrics more meaningful for stakeholders and simplifies data management. For mono repos or cross-domain boards, DevLake’s project mapping lets you associate multiple scopes (repos, boards, etc.) with a single project, so you can group related data even if it spans different sources source.

Tagging is now supported in DevLake, so you can assign tags to projects for filtering, dashboarding, and tracking by path, CODEOWNERS, or any other convention that fits your workflow source. This is especially useful if you want to create broader projects (like “backend”, “web”, or “mobile”) and then use tags to slice data by domain, team, or use case.

If your teams use boards that aren’t tied to a single repo or domain, you can include those boards in multiple projects or use tags to track cross-team work. For large setups, some users create projects with many repos and boards, then rely on multi-project dashboards and tags for company-wide metrics aggregation source.

In short: organize projects by domain or product line if possible, use project mapping to group related scopes, and leverage tags for flexible filtering and reporting. This approach scales well and keeps your data model aligned with your organization’s structure and reporting needs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}