Review Process
The Certified review process is conducted by a designated admin reviewer who evaluates each application against a standardized scorecard — ensuring consistent, objective certification decisions.
What the Reviewer Evaluates
| Criterion | What Reviewer Checks | Pass / Fail |
|---|---|---|
| Documentation quality | Opens the submitted URL. Verifies: install guide is present and clear, configuration options are documented, at least one example use case is shown | Pass = all three present; Fail = any missing |
| Test coverage report | Opens the uploaded report. Verifies: dated within 30 days, shows ≥80% coverage overall, report matches the package being reviewed | Pass = all three verified; Fail = any issue |
| Security scan | Checks the automated rescan result from submission time — not re-run manually | Pass = no Critical/High; Fail = any Critical/High present |
| Open critical issues | Checks the publisher's issue tracker for open Critical issues against this package | Pass = 0 open Critical; Fail = any open Critical |
| Changelog completeness | Reads the version history — verifies each version has meaningful entries (not "bug fixes" with no detail) | Pass = all versions have meaningful entries; Fail = gaps or vague entries |
Review Scoring
The review uses a pass/fail approach — each criterion either passes or fails. All five criteria must pass for Certified to be granted. There is no partial certification or weighted scoring — every criterion carries equal weight.
Review Outcomes
| Outcome | What Happens | Publisher Notification |
|---|---|---|
| Approved | Certified badge applied immediately. 100 rep points credited. Certified Publisher badge granted if first cert. | Email: "Congratulations — [Package Name] is now Certified" |
| Rejected | No badge applied. Package remains at Community. Feedback provided listing specific failing criteria. | Email: "Certification decision — [Package Name]" with detailed feedback |
After Rejection
Rejection is not permanent — the publisher can address the failing criteria and reapply. There is no cooling-off period between applications. The rejection feedback is specific about which criteria failed and what needs to be corrected.
The most common rejection reasons are: documentation that lacks a configuration reference, test coverage reports dated more than 30 days ago, or changelogs with vague entries. These are all quick fixes for a motivated publisher.