Redmine

Well, for us trackers belong to different teams with different workflows. For example, bugs tracker "belongs" to validation team while features tacker "belongs" to developers team, which means people don't have the same interaction permissions depending on their team.

Categories are just sub-information within a consistent set of tickets (consistent set = one tracker), we rarely use it and only for specific needs like gettings bugs impacting a given module in the software.

Moreover, trackers natively appear as options in many pages for categorized display (e.g project overview) or direct filtering (e.g roadmap) therefore we use trackers as the frontier between data that we won't analyse in same time because we know we can easily filter out tickets in one click everywhere.

Do you find people subscribe to the activity of their particular team's tracker and follow it, or do people subscribe to the main aggregate activity and follow that? Are the activities of the different trackers/teams compartmentalized enough that people across the whole project only need to check in on other trackers' progress at weekly meetings? Or that the work of the validation team rarely butts-up against/stops for/interferes with (constructively or otherwise) the activity of the other trackers?

For example, in my work, dialogue editors rarely have issues that conflict or involve sound effects editors, but we try very hard to keep them from getting silo'd, because they're all working in essentially the same phase of production, "editorial," and have to have awareness of the stuff that's going on in their particular part of the project (their scene, or their reel). But it seems like trackers on software projects collect people together by competence or skillset.

Categories are just sub-information within a consistent set of tickets (consistent set = one tracker), we rarely use it and only for specific needs like gettings bugs impacting a given module in the software.

That's interesting. Modules are a bit like scenes or reels in my case -- a scene will interact with other parts of the film, but it's mostly self-contained and it can change a great deal without requiring changes in other places.

Thank you for your response.

Jamie Hardt wrote:

Do you find people subscribe to the activity of their particular team's tracker and follow it, or do people subscribe to the main aggregate activity and follow that?

people subscribe to activity of any trackers they are involved in, even trackers their team does not own. Owning a tracker means only having more privileges on it, especially e.g moving a ticket status to "Done". It's not watching only that tracker.

Are the activities of the different trackers/teams compartmentalized enough that people across the whole project only need to check in on other trackers' progress at weekly meetings? Or that the work of the validation team rarely butts-up against/stops for/interferes with (constructively or otherwise) the activity of the other trackers?

It would be true if a given tracker covered the activity of one single team and other teams didn't care about this activity.
This is not the case in my work, as in any software dev. company. For example, a tracker for bugs will involve the testers team (filing the bug, giving more details, testing the correction), the developers (fixing the bug, porting the correction to other branches, ...), the managers (communicating with impacted customers) and so on.

In summary, trackers don't delimit our teams activity, they delimit our software development activities, each of these activities involving different teams.

For example, in my work, dialogue editors rarely have issues that conflict or involve sound effects editors, but we try very hard to keep them from getting silo'd, because they're all working in essentially the same phase of production, "editorial," and have to have awareness of the stuff that's going on in their particular part of the project (their scene, or their reel). But it seems like trackers on software projects collect people together by competence or skillset.

Yes, silos are also our main concern and the reason why we are very careful in the way we organize our projets, trackers and roles.
We actually build a community gathering all teams at redmine project level: a project contains several trackers and its members come from all teams, with different roles. As explained above, trackers are there for tickets triage only and don't split the community within the project.
And we never mention a tracker as a meeting point, we mention the project.

Categories are just sub-information within a consistent set of tickets (consistent set = one tracker), we rarely use it and only for specific needs like gettings bugs impacting a given module in the software.

That's interesting. Modules are a bit like scenes or reels in my case -- a scene will interact with other parts of the film, but it's mostly self-contained and it can change a great deal without requiring changes in other places.

Thank you for your response.

Thanks to you, it's really interesting to get experience from people in other fields than software coding.