Open erjosito opened 1 year ago
@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 topics
to schema in #445
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.