This page describes what you will see at each stage of the submission process and hilights some points of what you need to do next.

Step 1 — Open the Form¶

Log into GitHub and go to the submission form chooser and select the form for the current stage. The Submission Guide describes which form to use and in what order.

Each form opens as a structured GitHub issue. Fill in the fields, read the collapsible guidance (▶)!, and then submit.

This generates an issue with your submitted information¶

Step 2 — Automated Validation¶

On submission a workflow action proceses your information and tries to create the relevant files. It also performs a number of rudamentary checks on the information provided. After a couple of minutes you will get one of the following commented on your submission.

If validation fails, a comment is posted on your issue it should explain exactly which fields need correcting. No pull request is created as the User will need to to make these changes first.. Edit the issue body to fix the problems — the action re-runs automatically on every edit, so there is no need to close and reopen the issue. Repeat until the comment reports a clean result.

If validation passes, the action creates a JSON record and opens a pull request targeting the src-data branch. A comment on your issue links directly to the new PR.

Step 3 — The Pull Request and its Report¶

The pull request the action opens contains two things:

• the diff (a single JSON file showing the data that will be added to the registry) and
• a summary report posted as a PR comment.

The report shows the file created from your submission. If we are submitting groups a temporary ID will be assigned to the record (e.g. tempgrid_username-1234), and a link back to the originating issue. Additionally for grids we will also run a duplicate check, comparing your submission against all existing records and posts a comment if a match is found.

The PR is also added to the Reviewer Project Board and the needs-review label is applied to your issue. You can track all your open submissions from the My Issues link.

Step 4 — First Review¶

A reviewer reads the pull request — examining the JSON diff and the summary report — and either approves or requests changes. Any suggested corrections will be left as a comment on the original issue, not the PR. Edit the issue body to make the changes; the action re-runs and the PR updates automatically.

Once the reviewer is satisfied they approve the PR. This removes the needs-review label from your issue and moves the PR to the Done column on the project board.

Step 5 — Second Review and Merge¶

A second reviewer or maintainer performs a final sanity check and then triggers the merge. Before the merge completes, an automated merge gate validates the JSON against a set of required fields. If the validation fails at this point the merge is blocked and you will need to correct the issue body again. If it passes, the PR is merged into src-data and will appear on the docs pages emd.mipcvs.dev.

Step 6 — Publication and ID Assignment¶

Once merged, a publication pipeline runs automatically:

1. The new record is synced to the production branch and your temporary ID (tempgrid_*) is replaced with a permanent one (e.g. g112).
2. Linked-data graph files are regenerated.
3. The documentation site is rebuilt and deployed to GitHub Pages.
4. Issue form dropdowns are updated so the new ID is available for selection in subsequent stages.

This takes a short while. Your permanent ID will appear in the relevant form dropdowns by the next time the templates are regenerated (daily, or after the next publication run). This will also be posted on both the pull request and original issue (submission).