Offer an approved alternative, a standard library option or a path to a conditional approval with every rejection. Keep a short, maintained list of preferred packages for common needs so reviewers can answer in minutes. A bare "no" tends to produce a workaround.
Why alternatives pay off
Every rejected request represents a developer with a job to finish. If the answer is only no, they will look for another route, including routes you cannot see. An alternative keeps the work inside the controls and shortens the queue, because the next developer with the same need finds the answer already written.
Build a preferred list
Start with the needs that come up repeatedly: HTTP clients, date handling, JSON and XML parsing, logging, cryptography wrappers, test frameworks, command line parsing. For each need, record:
| Field | Purpose |
|---|---|
| Need | What the developer is trying to do |
| Preferred package | The approved choice and version scope |
| Why preferred | Maintenance, security record, licence fit |
| Language or standard library option | Often the simplest answer |
| Known limits | When the preferred choice does not fit |
| Owner and review date | Keeps the list alive |
Do not rank vendors or products as winners in public. Inside the company, a preferred list is a guideline, and exceptions are allowed with a reason.
The rejection reply
Use a short template:
- The decision and the reason in one or two sentences.
- The nearest approved alternative, with a link to its entry.
- What would change the decision, such as a fixed version or a different licence.
- How to appeal, and who decides.
For example: rejected because the current version has an unfixed advisory that is reachable from your described use; the approved alternative covers the same need; we will revisit when a fixed release appears.
Keep the list healthy
- Review it each quarter and retire entries that lost maintainers. Our post on maintainer health signals lists what to watch.
- Add an entry whenever the same rejection happens twice.
- Track how often the list answers a request without a full review. That is a useful measure of whether it works.
Handle the case of no alternative
Sometimes nothing approved fits. Options include writing a small internal implementation, sponsoring or contributing fixes upstream, approving with conditions, or accepting a time limited exception with an owner. Our exception request template for an unapproved package is a starting point.
Quick check
Is a preferred list the same as an approved list?
Not quite. The approved list says what is allowed. The preferred list says what to pick first for a given need.
Should rejections be shared?
Internally, yes, in a searchable place. It saves repeated requests.
Safeguard dependency scanning and policies can help identify risky packages before a request is filed. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
