From f79bfe6515fec7d5940a000276fa5ade99468428 Mon Sep 17 00:00:00 2001 From: Kylie Hunter Date: Mon, 30 Sep 2024 17:56:15 -0400 Subject: [PATCH] [skip ci] Correct grammar, editing-edit per review Co-authored-by: Gabeblis --- documents/adr/0009-constraint-based-help-docs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documents/adr/0009-constraint-based-help-docs.md b/documents/adr/0009-constraint-based-help-docs.md index 85af13cdf..c5d518e44 100644 --- a/documents/adr/0009-constraint-based-help-docs.md +++ b/documents/adr/0009-constraint-based-help-docs.md @@ -60,7 +60,7 @@ There are positive and negative impacts to each of the five solutions above. Bel 1. This approach has the lowest risk and effort for the FedRAMP Automation Team and maintainers of tool and data dependencies. However, it assures increased effort for developers of FedRAMP software and amplifies that same effort on downstream stakeholders who understand program requirements through those tools. This effort and friction will increase as the number of constraints increases over time. Operationally, tools will operate as they currently do at the time of this writing, so there will be no change in speed or performance characteristics of the tools. -1. This approach requires moderate effort for FedRAMP Automation Team developers maintaining constraints and developers of software for the FedRAMP ecosystem. The former will have to carefully editing new and existing constraints to track inserting additional information into the `message` field of a constraint. Downstream developers of software for the FedRAMP ecosystem will have to customize their tools to parse each message and extract different kinds of error information from the Metaschema modules or SARIF output without consistency and added complexity. It will, however, require little to no additional effort for maintainers of data and tool dependencies. Operationally, this may increase the size of constraint files and resulting results output in SARIF if guidance requires them to be output in all cases. +1. This approach requires moderate effort for FedRAMP Automation Team developers maintaining constraints and developers of software for the FedRAMP ecosystem. The former will have to carefully edit new and existing constraints to track inserting additional information into the `message` field of a constraint. Downstream developers of software for the FedRAMP ecosystem will have to customize their tools to parse each message and extract different kinds of error information from the Metaschema modules or SARIF output without consistency and added complexity. It will, however, require little to no additional effort for maintainers of data and tool dependencies. Operationally, this may increase the size of constraint files and resulting results output in SARIF if guidance requires them to be output in all cases. 1. This approach requires a nominal increase in effort for FedRAMP Automation Team developers, but for certain edge cases complicates design and implementation as such a property will be required. It will also cause a nominal increase in effort developers of software for the FedRAMP ecosystem, but give them a consistent way to extract necessary help documentation without ad-hoc parsing of the message field. Operationally, this approach will increase the size of constraint files and may increase resulting results output in SARIF if guidance requires them to be output in all cases.