-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add variant support for checks #438
Comments
@erjosito - I think this works well for the needs. The only alternative that comes to mind would be to add more specific properties like "useCase", "projectScope", "targetAudience", etc but that is less flexible to change and use. As long as we have some consistency in the list values for the "topics" we should be good with this. We want to avoid having items defined with "alz" vs. "azure-landing-zones" vs. "AzureLandingZones"... we can handle for that during PR reviews though. |
I think an array/list works nicely. And I'd recommend we add a JSON schema file to help restrict and control consistency in the JSON files for the checklists. As per: https://json-schema.org/understanding-json-schema/ An example I have implemented here https://github.com/Azure/CAE-Bits/blob/main/schemas/schema.metadata.json Happy to help. This also is auto supported by vscode etc. |
A schema is already included, see https://github.com/Azure/review-checklists/blob/main/checklists/checklist.schema.json |
Added |
A field should be added to checks so that you can have a filter to import it or not. This filter should not be binary, but a list of tags, so that different types of reviews can be performed, either with different depths, focus areas or approaches.
A possibility would be adding the field
topics
as a list, which could contain values such asdesign
,implementation
,alz
, etc.Each checklist client would then decide whether importing all
topics
, or just a subset.The text was updated successfully, but these errors were encountered: