In Bugsink, the primary way to organize issues is a project.
You probably already know what constitues a “project” for you. If so, feel free to just create a Bugsink project for each of those.
If you don’t, the main to remember is that Bugsink is all about tracking bugs in running software. That means that components that run independently (and do not share most of their code) should probably be separate projects.
If you deploy various components of your codebase independently, considers making each component that is independently deployed as a separate project. This is especially true if you keep track of versions or releases for such components.
On the flip side: if there is some shared code that is not independently deployed, e.g. if you have some library that is used by multiple projects, it probably should not be a separate project in Bugsink.
Further (related) guidelines are:
Microservices Architecture: If your app is composed of microservices, assign each service to its own project. Similarly, if your app has a clear separation between the frontend and backend, it can help to create a project for each.
Developer responsibility: If different groups of developers are responsible for different parts of the codebase, create projects that reflect this. Doing so will allow Bugsink to present the right issues to the right people, and/or notify the right people when issues occur.
Multiple Languages: For mixed-language projects, create a project for each language. For example, NodeJS and Java components should be separated into distinct projects.
Version Control Repositories: if you have multiple repositories in your Version Control System, you may want to create a project for each. (See the note about libraries above, however).
There is no limit to the number of projects you can create in Bugsink, so don’t be afraid to create a new project for each new component or service you start working on.
Next: Teams
