required vs optional compatibility

[jwillenbring]

As an ECP SDK lead I want to be able to see the level of required and overall policy compatibility so that teams can get a more complete view of their policy compatibility status.

Parent	Children	Related	Blocks	Depends On

Acceptance Criteria:

It is possible to see in some way both required policy compatibility and optional compatibility. This includes entirely optional policies (future policies) and optional components of required (current) policies.

Description, Additional Detail, Context:

This use case needs to be developed more before it can be worked. I see a couple possible ways that optional parts of policies might play out, but we have not gotten far enough to see if it is accurate. I could see having n parts of the policy (items on a PTC) and having some of those items required, and others optional. For example, maybe items 0-2 are required, and 3-5 are optional. Additionally, I could perhaps see where a policy might require items 0-1, and then 4 total, so 0-1 + 2 + 4 would work, as would 0-1 + 3 + 5.

Implemented By Task(s):

• Task: <task url or ID>

[elaineraybourn]

Additional detail provided by @jwillenbring on May 3, 2021 below:

If we map policies to the “better” categories, for example, better planning, and the components of those policies to the different practices in each area, we have a really great starting point. There are some things would require additional work however.

1.  For this usage, it would be critical to be able to write the results out, for example to some yaml file. The purpose of using such a tool would be to simplify the process of documenting policy compatibility for product teams. I know that this goes against the core usage of the tool. I am not sure what that means for potential path forward, or if that is a major hurdle.
   

2.  Similarly, it would be very useful to be able to read in a yaml file, or some other kind of file, we are not set on using yaml, but that is what has been used for the effort so far. Reading in a file would allow teams to pull in last year’s data and update it without starting over.
   

3.  There are some policies that we would like to be able to associate data with. For example, one part of one policy might have a text field for an explanation, or another might allow for a URL where the requested piece of data lives.
   

4.  There are currently 9 policies. That could grow. We may need some way to visually represent the big picture that would not become too fine for a larger number of policies. This may not be a big issue. I am not sure.
   

5.  We may need to extend the visual component of compatibility. There will be policies for which we are tracking data that goes beyond the minimum required. We would need some way to show the compatibility level with the minimum standard, and also with the optional items. I am not sure if this would be in the same figure or not.