Defining tree versions #303
Replies: 8 comments 16 replies
-
Outcome Sets are not includedWhile the set of decision points and their combinations of values define the structure of a tree, an Outcome Set defines the possible labels of each leaf node. However, in order to decide what labels are appropriate for a leaf node, one must also be given a policy that maps each input combination (specific decision point values) to a specific outcome (drawn from an outcome set). But both the policy and the outcome set are actually stakeholder-specific. The example trees we provide are at best a guess at a reasonable policy for SSVC adopters for each of the decisions we chose to model. And they also make assumptions about the process that the decision supports. So we assumed that suppliers have four options for priority. And we assigned outcome labels to leaf nodes based on what seemed reasonable to us at the time. But we must acknowledge that (a) stakeholders might have an arbitrary number of categories for prioritization (2, 3, 4, 5, ...), and (b) they may have wide variation in what combinations are given which priority. Thus, the reasoning behind omitting outcome sets and specific outcome labels from the tree identity is as follows:
Note that 2 subsumes 1, in that 1 maintains the same outcome set and just modifies the mapping, whereas 2 allows the outcome set to change. The thing we're asserting is that the structure of the tree (as defined by its constituent decision points and their specific versions) is invariant to the above, therefore the tree's identity omits both the outcome set and its specific mapping to the tree structure. |
Beta Was this translation helpful? Give feedback.
-
On the naming and versioning of treesAlthough the identity of a tree is fully defined in the initial post of this thread, it seems unreasonable to expect anyone to recognize that the object
is related to a patch supplier's choice to create a fix, whereas
is related to a Coordinator's choice of how to handle a report. So the first point to make is: Trees have namesA tree name should be short, succinct, indicating both the Role and the relevant decision it applies to. We've already established this principle in practice. The first object above has the name "Supplier Priority" while the second is "Coordinator Triage". Trees have versions?This is an unresolved part of the conversation. The name "Deployer Priority" (or "Deployer Tree", we haven't been super strict on naming consistency) has been used to describe what we're now saying are two distinct tree identities. SSVC version 1 had Patch Applier Tree
SSVC version 2 added Automatable and Value Density (combined as Utility), and combined Mission and Safety into Human Impact, but since we're sticking with the atomic decision points as identifiers, I'll maintain the expansion here. Deployer Tree
While SSVC version 2.1 dropped Value Density, leaving: Deployer Tree
My argument is that these three objects represent versions 1, 2, and 3 of "the thing" where "the thing" is defined by the role and decision it is modeling. In other words, attributes that make for good tree names (role, decision) make good names for a reason: because they describe an identity. Above, I deliberately ignored our choice to shift terminology from Patch Applier to Patch Deployer as I think this is a refinement of our understanding but not a meaningful semantic change in who we expected the audience for that tree to be. But it does show up in point 3 below. So a versioning rule for trees could be:
3 . Tree name aliases are permitted and do not trigger version increments Given the above, the Deployer <=> Patch Applier alias by itself is a non-versioning event, but the addition of Automatable and Value Density (as Utility) implies the tree version should increment by 1.0. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure I support the idea of versioning trees. |
Beta Was this translation helpful? Give feedback.
-
Tree versioning, version 2A second approach to tree versioning that has been suggested is:
Note that this is basically the "status quo" option, as it is how we have to refer to them as it stands because we haven't yet resolved the versioning conversations. |
Beta Was this translation helpful? Give feedback.
-
So which are we going to version: the trees, the decision points, or both? Regarding the table: How would someone find the reasoning behind the changes to the trees? In this chart the changes are obvious, will the charts be included and updated as part of the documentation? |
Beta Was this translation helpful? Give feedback.
-
To be discussed, we could mean something else, but this is the kind of
thing I have in mind when I think about a user story and what it should
contain at what level of detail.
https://www.atlassian.com/agile/project-management/user-stories
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
This discussion is largely now the subject of Issue #355 and any subsequent PRs that will resolve it. Leaving the discussion open until #355 is closed. |
Beta Was this translation helpful? Give feedback.
-
We've talked about this within the team already, but it's time to write some of it down.
I'm going to start with a premise that I think we have agreement on:
Decision Tree identity is the specific set of versioned decision points
Assumption: Decision Points are versioned objects as per #289.
Identity: A Decision Tree's identity is fully defined by the specific names and versions of the decision points it contains.
Because we have not yet explicitly versioned decision points, I can only specify them by name, but a "real" definition would require the version of each decision point to be specified as well.
Note that it's a set not a list, the order does not matter.
For example, the Coordinator Triage tree appears to be identified by:
Coord Triage Tree
Except that Utility and Public Safety Impact are compound elements for notational convenience only, so we should represent them as their constituent parts.
Coord Triage Tree (all decision point versions TBD)
The Supplier tree, subject to a similar substitution of constituent decision points for Utility and Public Safety Impact, is defined as:
Supplier Tree (all decision point versions TBD)
Beta Was this translation helpful? Give feedback.
All reactions