Additions to JSON schema

[kaitj]

Wanted to start a discussion on this before going too deep into this. Currently, there is a difference in the schema used over in the standards-checklist repo and data structure in this proceedings repo as noted in this issue comment and also relates to #1. I believe this was part of why the back_migrate.js script was created - to make the submitted checklist version compatible with all the additional fields in the data structure mocked. Every time the proceedings page is deployed, all of the checklists are "migrated" with a new created version (hence the last review date == deployment date).

I would propose adding a few additional fields to the schema itself to retain the useful fields from the data structure without having to make changes to the checklist:

• checklistVersion - this can be set in the checklist actions workflow
• evaluationDate - this can also be set in the checklist actions workflow
• evaluators - if set as issue assignees, then usernames and profiles can be fetched from the github api during the actions workflow as well
• history - link to the commit history of a checklist
• image - (optional) hardcoded for now to retain the brain image currently displayed, but eventually add to checklist?

{
  ...
  "properties": {
    "checklistVersion": {
      "title": "Checklist version",
      "type": "string"
    },
    "evaluationDate": {
      "title": "Checklist evaluation acceptance date",
      "type": "string",
      "format": "date"
    },
    "evaluators": {
      "title": "Evaluators",
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": {
            "title": "Evaluator",
            "type": "string"
          },
          "contact": {
            "title": "Github contact",
            "type": "string"
          }
        },
        "additionalProperties": false
      }
    },
    "history": {
      "title": "Checklist evaluation history",
      "description": "Link to github commit history to see changes between evaluations",
      "type": "string",
      "format": "uri"
    },
   ...
}

toolVersion is another potentially useful one to include as part of the checklist itself, but would potentially be a field we would want to include on the checklist page, so leaving that out of this discussion for now.

With some further changes, the submitted checklists could be used directly without the need for migration. The main motivation for this is to have the schema and data structure in the two repos "synced", with the larger goal of also including a comments text-field to each checklist item, which would also require a change to both the schema and data structure anyways. This would also hopefully make future desire checklist changes easier to integrate as well.