For a consortium leader, improving metadata across your membership is not a technical problem — it is an organizational change effort. And the good news of organizational change is that the solution usually already exists inside the organization: some of your members are already doing this well. These tools help you find them, understand what they do, and spread it.
This guide assumes you know what the tools do individually — if not, start with the Repository Guide. Here the unit of analysis is not one repository but your whole membership.
The core idea — bright spots. In any community facing a hard problem, a few members succeed with the same resources and constraints as everyone else. This is the positive deviance approach, and the "find the bright spots" move from Chip & Dan Heath's Switch: instead of analyzing what's wrong everywhere, find what's working somewhere and clone it. Your job is less "fix 40 repositories" and more "find 3 that figured it out, and rally the other 37 around them."
Why bright spots work for metadata
Switch frames change as three moves, and each one maps directly onto consortium metadata work:
Direct the Rider — vague goals stall. "Improve your metadata" is vague; "do what the University of X did with affiliations — here is exactly what changed in their records" is a script your members can follow. The tools give you the script.
Motivate the Elephant — mandates and deficit reports drain energy; visible progress builds it. Celebrating a member's jump from 40% to 90% funder identification does more for the next member than any requirement document.
Shape the Path — shrink the change. "Adopt persistent identifiers" is a program; "paste this list of 200 affiliations into the ROR Retriever and get identifiers back this afternoon" is a task. The retrievers exist to make the first step small.
The playbook
A membership-wide effort, step by step. Steps 1–3 are measurement; 4–5 are learning; 6–7 are outreach.
1
Know your members as DataCite sees them
Every repository in DataCite is a client with an ID like abcd.xyz — that ID is what every tool takes as input. Your consortium's organizations are providers, and their repositories are the clients underneath them.
List an organization's repositories: api.datacite.org/clients?provider-id=<org-id>
List your consortium's organizations: api.datacite.org/providers?consortium-id=<consortium-id>
Or browse your members on DataCite Commons — each repository page shows its client ID.
You'll end with: a list of member client IDs — the roster for everything below.
Run each member through the completeness tool with the same settings (same Max, random sampling on) so the numbers are comparable, and export the JSON or HTML report for each. This is a run per member — an hour of clicking for a mid-sized consortium, and you only need to redo it once or twice a year.
Record more than the total: note each member's score on the four FAIR use cases and the Project use cases separately. Bright spots are usually specific — a member that is ordinary overall but 95% on affiliations is exactly what you are looking for.
You'll end with: a comparable scorecard across the membership, per use case.
3
Find the bright spots — per practice, among peers
Look down each column of your scorecard, not just the totals. Who leads on funder identifiers? On ORCIDs for creators? On related identifiers? Use Metadata Connectivity on the leading candidates — its identifier-by-identifier view is the sharpest lens for connectivity practices.
Positive deviance has a rule worth keeping: compare members with the same constraints. A well-staffed data repository outscoring a one-person institutional repository is not a bright spot — it's a budget. A one-person repository at 90% affiliations is one, because its practice is adoptable by its peers. Use the resource-type filter to compare like with like.
You'll end with: a shortlist: 2–4 members, each bright at something specific.
A bright spot that improved is more useful than one that started strong, because improvement is the thing you're asking everyone else to do. For each shortlisted member:
Repository History — did the use-case lines jump in a particular year? That's when something changed.
Re-Curation Watch — open records from around the jump and read the before/after diffs: what exactly was added — affiliations? funder identifiers? — and by whom?
Repository Activity — was it a one-time cleanup or a sustained practice, and which properties get the attention?
Then do the thing the tools can't: call them. The tools tell you what changed and when; only the member can tell you how — the workflow, the staffing, the trigger. That conversation is the heart of the positive-deviance method, and it also recruits your bright spot as a willing leader rather than an example held up without warning.
You'll end with: two or three concrete, peer-tested practices with named, willing champions.
5
Turn measurements into stories
Numbers direct the Rider; stories move the Elephant. Every tool exports what you need for outreach without extra work:
Completeness HTML/PDF reports and plots — a member's before/after, side by side.
Repository History PNG charts — the improvement curve, which is the most persuasive single image you can put in a newsletter.
Re-Curation Watch timelines — the visible fingerprint of curation work.
Every view has a bookmarkable URL — put live links in your outreach so members can see the real thing, and their own repository, in one click.
Celebrate in public, coach in private. Name the bright spots and what they did; never publish the bottom of the table.
You'll end with: outreach material: "here's what X did, here's the curve, here's how to start."
6
Shrink the change for everyone else
The distance from "we should adopt PIDs" to a first fixed record is where change efforts die. The tools compress it:
In Metadata Connectivity, every bar drills down to the exact records and names still missing identifiers — a to-fix list, not a percentage.
One click hands the unidentified affiliations to the ROR Retriever and the unidentified people to the ORCID Retriever, which return the identifiers ready to add.
A member's first win can genuinely happen in an afternoon — and per Switch, the first win is the one that matters.
You'll end with: a starter task any member can complete in one sitting.
7
Rally the herd, then re-measure
Behavior is contagious in communities — that's the "herd" in Switch and the reason consortia can move faster than isolated repositories. Put bright-spot members in front of the membership (webinars, working groups, office hours) and let peers teach peers; it lands differently than guidance from the consortium office.
Re-run the baseline on the same settings once or twice a year. Improvement you can show — member by member, use case by use case — is both your progress report and your next round of bright spots.
You'll end with: a repeatable annual cycle: measure → find → learn → celebrate → shrink → spread.
Bright spots are not a league table. Positive deviance works because peers learn from peers; rankings work on nobody. Publish who's bright and why; keep the rest of the scorecard for private coaching conversations.
Compare like with like. Repository type, discipline, and staffing all move the numbers. Use the resource-type and query filters, and treat cross-type comparisons as context, not competition.
Completeness measures presence, not quality. A 100% concept means the field is there in every record — a necessary start, not a finish line.
Keep sampling settings constant. Same Max, random sampling on, for every member and every re-measurement — otherwise year-over-year changes may be sampling noise.
History is a cohort view. Repository History scores records as they are today, grouped by the year they were registered — so re-curation lifts past years too. That's a feature for this work (it shows curation reaching back), but say so when you present the curves.
Where to go next
Repository Guide — the tool-by-tool first session, for you or for members you're onboarding.
