Store shared contributor details once, and put each project-specific role and display position on the credit connecting that person to a project. This lets one person have different credits without maintaining duplicate biographies.
If editors manage ordered credit lists within projects, start by evaluating project-owned entries. If they need direct access to individual credits, central review or cross-project lists, compare separate credit records. Neither structure automatically supplies the required editing screens or queries.
Start with two existing projects that share a contributor. For each value, ask: should changing this update the person everywhere, or only their appearance on this project?
Map each value to its owner
Write a field-ownership map with three parts:
- Person: a stable identifier, current display name, shared biography, portrait and profile links, where needed.
- Project: a stable identifier, project title, description and other details about the work itself.
- Credit: the person reference, project connection, role label, display position and any project-specific credit note.
Here, role means a public credit label, not a WordPress account permission.
Consider a hypothetical portfolio where Maya Chen is a Designer on Harbor Pavilion and an Adviser on Field Atlas. A handoff sketch could look like this:
- Person person-014: Maya Chen; her current shared biography, portrait and profile links belong here.
- Harbor Pavilion, project-101: a credit references person-014, with role Designer and display position 2.
- Field Atlas, project-102: a credit references the same person-014, with role Adviser and display position 1.
These identifiers and positions are invented examples. The positions describe Maya’s place in each project’s contributor list, not a global rank or recommended default.
For a credit stored inside a project, the owning project can supply the project connection. A separately managed credit record needs an explicit project reference as well as a person reference.
A general professional description such as “Designer and researcher” can belong on the person, but it should not substitute for a project credit.
If published credits must preserve historical names or biographies, document that separately. Current shared details and deliberately frozen historical values serve different purposes. Do not let a shared-profile update overwrite historical text that was meant to stay fixed.
Compare structures by the work editors must do
Project-owned credit entries
With this structure, an editor opens a project and manages its credit list there. Each entry selects an existing person and stores the local role, ordering and any credit-specific note.
This is a reasonable starting point when the main tasks are adding contributors, correcting their roles and arranging an ordered list on a project page. Credits do not need their own independent review or publishing process.
Repeating credit entries is not the same as duplicating people. The entries repeat the relationship, not the biography. The intended display should obtain shared details from the referenced person and local details from the credit.
A person page listing their projects does not automatically rule out this approach. However, retrieving those connections must be designed and verified for the chosen storage structure.
Separately managed credit records
A separate credit record gives the connection its own identity, with references to one person and one project plus its credit-specific fields.
Compare this approach when editors need direct access to individual credits, a central review queue or a cross-project list of credits awaiting correction. It may also suit a requirement to retrieve credits by their own properties, such as every Adviser credit across the portfolio.
Those needs are reasons to compare implementations, not proof that separate records are the only solution. Separate records do not automatically provide better filtering or review screens.
The trade-off is additional management. Editors still need a convenient way to add credits from a project, and the implementation must handle missing references and project-specific ordering deliberately.
Write a concrete implementation handoff
The finished handoff should let a developer explain how the model will be stored, edited and displayed. Record these decisions:
- Chosen structure and reason: identify the editing or retrieval requirement that drove the choice.
- Field ownership and sample records: include the map and two-project example above, adapted to your content.
- Required editing screens: specify where editors select existing people, correct roles, reorder credits and remove a connection without deleting the person.
- Required retrieval views: name the ordered project list and any needed person-to-project listing, role filter or review view. Distinguish required views from optional ones.
- Multiple-role policy: decide whether one person with two roles on the same project gets one credit with multiple labels or distinct credits with separate ordering.
That last decision matters for duplicate prevention: a rule intended to stop accidental repetition must not block a valid contribution pattern.
Repeatable credit entries and linked credit records both require an implementation choice. Do not assume a standard WordPress installation supplies the proposed fields, selectors, relationships or query interfaces. Ask the developer to explain how each required task will work.
If migrating existing credits
Map old entries to stable person identifiers before combining records. Names alone are not enough to resolve identity: two people can share a name, and one person can appear under variations.
Resolve uncertain matches with the content owner while preserving each project’s role labels, ordering and notes. Do not merge ambiguous people merely to eliminate apparent duplicates.
Verify shared changes and isolated corrections
Run these manual acceptance checks in a development or staging copy using the hypothetical Maya example. Use exactly two contributors per project. On Harbor Pavilion, put Maya second and the other contributor first; on Field Atlas, put Maya first and the other contributor second.
These are expected outcomes to demonstrate, not claims about an existing implementation. Save and reopen the affected records, then inspect the rendered pages. Deliberately historical text should follow its separately agreed policy rather than the current-biography expectation.
Have your developer demonstrate the saved values and page output for this small case before moving the remaining credits into the chosen structure.
