v13: add curation checks documentation #796
Conversation
| ```python | ||
| { | ||
| "type": "field", | ||
| "path": "metadata.title" # Path to the field | ||
| } | ||
| ``` |
There was a problem hiding this comment.
I'm not sure how I feel about defining these "schema"-like structures as code-blocks vs. tables. An alternative would be to do something similar to JSDoc-like code blocks, see e.g. https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command
There was a problem hiding this comment.
from your link it just looks like a normal codeblock to me?
There was a problem hiding this comment.
also I think representing this as a table would be more confusing as you write and edit these in JSON
carlinmack
force-pushed
the
docs-day-curation
branch
from
d026c09 to
96565b5
Compare
carlinmack
changed the title
carlinmack
force-pushed
the
docs-day-curation
branch
from
6056473 to
6e5e00e
Compare
carlinmack
force-pushed
the
docs-day-curation
branch
from
6e5e00e to
e80a739
Compare
|
|
||
| Checks provide a way to run automated verification on draft and inclusion requests to communities. As such, checks require both: | ||
|
|
||
| * A **community** that has at least on check config defined |
There was a problem hiding this comment.
| * A **community** that has at least on check config defined | |
| * A **community** that has at least one check configuration (config) defined |
or keep with "configuration" throughout.
|
|
||
| ## Overview | ||
|
|
||
| Checks provide a way to run automated verification on draft and inclusion requests to communities. As such, checks require both: |
There was a problem hiding this comment.
v minor wording:
| Checks provide a way to run automated verification on draft and inclusion requests to communities. As such, checks require both: | |
| Checks provide a way to run automated verification on draft review requests and record inclusion requests for a given community. As such, checks require both: |
| A check component is the code which executes the check on the record in accordance with the `params` defined in the database. At current there are two check components defined: | ||
|
|
||
| * MetadataCheck — uses the [metadata check config schema](../../reference/checks_config.md) to verify the metadata of a record | ||
| * FileFormatsCheck - verifies the extensions of the records files to check if they are open. |
There was a problem hiding this comment.
minor just for super clarity
| * FileFormatsCheck - verifies the extensions of the records files to check if they are open. | |
| * FileFormatsCheck - verifies the extensions of the records files to check if they adhere to an open standard. |
| @@ -0,0 +1,214 @@ | |||
| # Metadata Checks Configuration Schema | |||
There was a problem hiding this comment.
placement discussion : would maybe place this in "Maintain and Develop" (even if it is a reference). It's not a general reference usable by many different kinds of users right? Maintainers and maybe operators only. Keeping it close to the other relevant doc makes it easier to grasp the concept in a one-stop-shop location.
❤️ Thank you for your contribution!