A c grade plugin is the one that survives a quick look and fails a slow one. That is what makes it the awkward category. A D grade is easy: nobody installs it. A C grade sits close enough to fine that teams approve it on the strength of a glance, and most of them never go back. This post covers c grade plugin risk in practical terms: what a C grade means on the 0-100 score, why borderline dsh plugins are the group most likely to slip through review, and how to settle should you install a C-grade plugin with three questions instead of a feeling.
What a C grade actually measures
The score is built from maintenance, documentation, npm health and ecosystem signals. A C grade does not mean the plugin is broken. It means several of those inputs came back middling at the same time, and none of them came back strong enough to lift the average.
| Signal | Typical C-grade reading | What it tells you |
|---|---|---|
| Maintenance | Last push two to five months ago | Nobody is actively fixing it, and nobody has abandoned it either |
| Docs | A short README, no upgrade notes | You will be reading the source to answer basic questions |
| npm health | Few downloads, version still moving | Small audience, so fewer people hitting the bugs before you do |
| Ecosystem | One maintainer, no dependents of note | If the maintainer stops, nobody picks it up |
Read together, that is a plugin that works today and has no clear plan for tomorrow. The scoring breakdown is at /blog/dsh-quality-score-decoded.
Where c grade plugin risk comes from
The risk is rarely in the code. It is in what happens after you depend on it, and a C grade is a forecast about that rather than a statement about quality.
- Time to fix. A plugin with a slow maintenance signal will not get a patch on your schedule. If the bug lands in your release week, you own it.
- Burden of understanding. Thin documentation moves the cost onto your team. Somebody reads the source, and that somebody is usually the person who approved it.
- Exit cost. A plugin nobody else depends on has no fork waiting when the maintainer stops. You either maintain it yourself or remove it.
- Silent drift. Middling plugins update without announcements. A version that worked last month can change behaviour without a note anywhere.
A C grade is a forecast about the next six months, not a verdict on the code you can read today.
Why borderline plugins slip through review
Reviewers have a fixed amount of patience and spend it where the signals are loudest. A plugin with a dangerous install script gets read line by line. A C grade plugin gets a glance, because nothing about it looks wrong.
- Nothing is obviously broken, so there is no trigger to dig deeper.
- The README answers the first question, which makes it feel documented enough.
- The score is not alarming, and not alarming reads as acceptable under time pressure.
- Nobody writes down the approval, so six months later there is no record of who decided and why.
The B-grade version of this conversation is at /blog/what-a-b-grade-dsh-plugin-tells-you, and the pattern is the same: the middle of the range is where judgement matters most and gets applied least.
When a C grade is fine, and when it is not
Plenty of C-grade plugins are the right call. The deciding factor is what the plugin can reach and how easily you can remove it.
- Fine: local-only tooling, one developer, no credentials, and a real uninstall path. The downside is a slow afternoon.
- Fine: a plugin you are evaluating for a week and will not ship. Score matters less when nothing depends on it yet.
- Not fine: anything on a shared build runner. A stalled plugin there stops the whole team, not one person.
- Not fine: anything that reads credentials, writes outside its own directory, or runs at install time. Those need a stronger grade or a sandbox, and the sandbox routine is at /blog/how-install-script-scanning-works.
Turning a C into a decision
Three questions cover most cases, and all three have short answers.
- What can it reach? Credentials, network, files outside its directory. Write the list down, because the answer decides everything else.
- How fast can you remove it? If the honest answer is that you have never tried, the plugin is riskier than the grade suggests.
- Who owns it after approval? A named person, not a team. Ownership is what turns a decision into a habit six months later.
If all three answers are comfortable, install it and put it on a watchlist. If any one of them is uncomfortable, the grade is not the problem, the fit is.
FAQ
- Is a C grade the same as unsafe? No. Safety and maintenance are separate axes. A well-maintained plugin can still have a dangerous install hook, and a neglected one can be harmless. Read both.
- Does a C grade ever improve? Yes, and it is worth watching. A release that updates dependencies and adds docs moves the number, which is why a watchlist beats a one-off check.
- Should we set a floor of B for everything? That blocks useful plugins and still lets risky ones through. Gate on what the plugin reaches, not on the letter.
- How is this different from a B grade? A B grade means most signals are fine with one weak spot. A C grade means several are middling at once, so the weakness is diffuse and harder to name.
- What if the plugin has no alternative? Install it, constrain what it can reach, and write the removal steps down before you need them.
Every plugin page at dshquality.com shows the signals behind its grade, so you can see which input dragged a C down rather than guessing. The score components are explained at /blog/dsh-quality-score-decoded, the case for keeping that scoring independent of self-reported data is at /blog/why-independent-plugin-scoring-beats-self-reported-ratings, and everything published on the site is at /blog.