Submission review processes

July 28, 2026 ยท View on GitHub

Guide for processing pending add-ons. If add-on needs manual review before processing happens, the submission process will be held, pending approval from NV Access. This is done using a deployment environment.

Overall process:

  1. Go to the pending add-ons list.
  2. Check the pending deployment environment.
    1. If it is submitterReview perform Process for first time submissions.
    2. If it is securityReview perform Process for flagged add-ons.
    3. If it is both, perform both steps.

Approving an author to submit to a particular add-on ID for the first time

When a GitHub user submits a particular add-on for the first time, the submission is blocked pending initial review from NV Access. This is to confirm that the GitHub user has authorisation to submit the add-on from the add-on maintainers. In some cases, 2 separate add-on maintainers may want to lay claim to a single "add-on ID". It is important for users to expect consistent authorship for a single add-on ID for trust and security reasons. It would be misleading and potentially risky to be encouraged to update to a fork or alternative add-on without permission from the original maintainers. See the submission guide for further reasoning behind this. This registration process ensures a specific add-on ID is only submitted by the same group of authorised maintainers.

Process for first time submissions

The process for reviewing pending first submissions is as follows:

  1. Open the referenced issue and related PR.
  2. Check the source code link in the referenced issue.
    • Ensure the submitter matches the repository ownership, or the submitter is a core maintainer for the project. If this is not the case, tag the core maintainer in the submission to confirm they give permission for the submission.
    • Check for any obvious red flags with the repository i.e. it doesn't look structured as an add-on, inappropriate content in the readme, author and code only been around for a few days
    • Ensure there is not a clash of add-on IDs by checking submitters.json for similar IDs.
  3. Approve or deny the submitterReview deploy environment.
    • If you are unsure, leave a comment outlining why the add-on is being left open and what's needed to decide how to process it. Tag another member of NV Access for a second opinion if needed.
    • When rejecting, the rejection message(s) are provided to the user as the closing reason(s). The issue and PR will be closed. Make sure to clarify any further information on the issue.
    • If the deployment review request has expired, close the PR and re-run the job.

Approving an add-on which was flagged as malicious

An add-on may be flagged as malicious by VirusTotal.

Process for flagged add-ons

  1. Open the referenced issue and related PR.
  2. A comment should appear on the GitHub issue with information on why the add-on was flagged.
  3. Consider if the flagged content is a false positive. This may require discussion within NV Access or with the add-on contributor.
  4. Approve or deny the securityReview deployment.
    • When rejecting, the rejection message(s) are provided to the user as the closing reason(s). The issue and PR will be closed. Make sure to clarify any further information on the issue.
    • If the deployment review request has expired, close the PR and re-run the job.