Understand the impact of a change
See which parts of the product a proposed change could affect.
Name a part of the product the way the product names it — "Subscription", "the upgrade flow" — and get back what a change there would reach in both directions: what depends on it, what it depends on, which areas it pulls in, and a risk level. A diff shows the files you touched; this shows what those files touch.
Name the thing you are about to change, in the product's own words.
Pick the right one if that name matches more than one thing.
Read the risk level and the areas it pulls in, before you start.
Walk the list of what depends on it, nearest first.
Reach is worked out from what the reading of the source recorded. A connection that exists only at run time — through configuration, or a call decided while the program runs — is not in it. Risk comes back as a level, not a number or a probability. It answers for one repository's reading at a time, so a change that crosses two repositories has to be asked about twice.
See it on a real product.
Three models are published in full and open without an account. Ask one of them the question this page is about.