It is most closely related to the last one, namely to quality criteria in terms of validation. And it goes beyond the fact that all models MUST pass validation, which has already been established via CI.
The question here is in how far we should accept WARNING or HINT messages that are created by the validator. For example, I think that the sample assets repo should not contain models that have obvious 'unused objects'. Other warnings might be acceptable, depending on the context. (This particularly refers to extensions that are not (yet) handled by the validator, and which will create a WARNING that has to be aticipated)
The exact list of "acceptable issues" has to be sorted out. This might include some infrastructure for the automated tests. For example, roughly like a ignoredIssue.json file that explicitly ignores a certain warnings during the validation.
This issue is related to some other ones:
It is most closely related to the last one, namely to quality criteria in terms of validation. And it goes beyond the fact that all models MUST pass validation, which has already been established via CI.
The question here is in how far we should accept
WARNINGorHINTmessages that are created by the validator. For example, I think that the sample assets repo should not contain models that have obvious 'unused objects'. Other warnings might be acceptable, depending on the context. (This particularly refers to extensions that are not (yet) handled by the validator, and which will create aWARNINGthat has to be aticipated)The exact list of "acceptable issues" has to be sorted out. This might include some infrastructure for the automated tests. For example, roughly like a
ignoredIssue.jsonfile that explicitly ignores a certain warnings during the validation.