User-oriented mental model for author corrections

I have been thinking about how we frame and organize different kinds of correction requests related to authors.

From the user's perspective, they don't care how our database works under the hood—they care about showing the correct info on the correct page.

Here is a breakdown of the operations that I can think of:

1. Does the author name reflect what is in the PDF? If not, **Paper Metadata** request. Under the hood: changes paper-level info only (which may have ramifications at the author-database level like adding a new name variant to a verified person, but this should be handled by the library)
2. Does the author page have the correct set of papers on it (all the papers by the individual person and none others)? If so, there are several operations that can collectively be called **Author Page Header Requests**:
- YES + it is an unverified page: **Verify-all** request. On the front end, changes the URL (removing `/unverified`) and the page header. Under the hood: at the paper level, makes author IDs explicit; at the author level, adds a verified person.
- YES + it is a verified author page: **Edit ORCID** (to correct an error, or provide ORCID for a legacy-verified author), **Change preferred name** (among known variants), **Change to semantic author ID** (with degree institution suffix rather than ORCID-based code), **Permanent name change**, **Add similar name of different person**. On the front end, these only change the top of the page, not the list of papers. Under the hood: all of these are simple changes at the author level. They affect an existing author entry in people.yaml. Changing the author ID will also update the paper XML entries linking to it, and the URL.
3. Otherwise, we need to change which papers are on which page—call these operations **Author Page Grouping Requests**:
- **Merge**: 2 author pages have papers that should be under the same person. What happens under the hood depends on which of these authors are verified already (if any).
- **Move-and-verify**: Create a new verified author page for a subset of the papers on this page. Under the hood: create a new verified author and link papers to it.
- **Move-to-verified**: Some (but not all) of the papers on this page belong to a different **verified** person. Under the hood, this means adding author IDs to the papers being moved.
- **Move-to-unverified**: Some (but not all) of the papers on this **verified** page of a currently unambiguous author name belong to a different unknown person, and belong on an unverified page. Under the hood, this means setting an author-level flag to disable listing papers on a verified author page based on string match.

Is this a reasonable characterization? If so, we can think about which interfaces/issue templates/scripts and processes are most appropriate.

Start by reviewing the existing people.yaml author records, paper XML author links, and any current issue templates or scripts for correction requests. Done means agreeing on the proposed request categories and defining the interfaces, templates, and processes needed to support them; the issue does not name a specific file or test to run.

由索引模型根据 Issue 内容生成。