Criteria for tracker being shared or branched

Question

Hi community,I am aware of the different behavior of links between different types of tracker (shared/branched) with regard to streams. But I was just wondering aboutWhat are criteria to configure a tracker as “branched”?	What are criteria to configure a tracker as “shared”?	In which use cases should links be placed upstream from the shared tracker to the branched tracker? (shared tracker → branched tracker)?	In which use cases should links be placed upstream from the branched tracker to the shared tracker (branched tracker → shared tracker)?I’m thinking about trackers of type releases, user stories, change requests, bugs, test configuration, test set, test runs...Does anyone have clear answers?BR,Markus

Brian Kampling · Answer

Hi ​@M a r k u SI like to save Shared trackers for items that live outside the normal version or variant control of a product under development and will not be impacted by whatever version or variant of that product is being developed. This could be things like values driven by an ISO standard or a regulatory body. Another good question is to ask, if this value was updated or changed, would it impact all versions or variants, or only specific ones. As for how to use them, I recommend having them be downstream, so the reference field is place on the tracker that is consuming them so suspect flags are visible if the shared tracker changes. For trackers like releases and change requests, that is going to be more process driven and case by case, but a good indicator is if you want to be able to go into the shared tracker and see multiple versions or variants together, such as managing multiple versions / variants of a product within a shared release cycle.Does this help?

Faça o registo

Utilize sua conta do PTC eSupport

Bem-vindo à Comunidade PTC

Utilize sua conta do PTC eSupport