internetarchive / internetarchive/openlibrary
Remove "primary" selection from author merge tool
- Dominant language
- Python
- Stars
- 6.7k
- Forks
- 2k
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 138
Description
### Proposal
Based on a discussion on [Slack back in July](https://internetarchive.slack.com/archives/C0119PRDV46/p1720553267251059?thread_ts=1720535164.469609&cid=C0119PRDV46).
We do not need to have a "primary" selection in the author merge tool.
As I understand it, @seabelis says we should always have the oldest OLID as the "primary".
As such, we can dramatically simplify the GUI the author merge (and later work merge) by removing the "primary" ratio button from the GUI.
On the backend, there will still be a primary but it should automatically be selected based on which is the oldest ID.
Current design of the author merge page

I imagine the end result should look something like this:

Perhaps we link to the docs for merging :)
### Justification
The main reason I want this change is to simplify the experience for librarians and keep our UIs nice.
### Breakdown
#### Requirements Checklist
* [ ]
#### Related files
*
#### Stakeholders
* @seabelis @cdrini
#### Instructions for Contributors
Please [run these commands](https://github.com/internetarchive/openlibrary/wiki/Git-Cheat-Sheet#working-on-your-branch) to ensure your repository is up to date **before** [creating a new branch](https://github.com/internetarchive/openlibrary/wiki/Git-Cheat-Sheet#making-changes-and-creating-a-pull-request) to work on this issue and **each time after** pushing code to Github, because the pre-commit bot may add commits to your PRs upstream.
Contributor guide
Research direction
Start by locating the author merge page and the backend handling for author merges. Confirm how the current primary radio-button selection reaches the backend, then verify that the interface no longer presents it and that the oldest OLID is selected automatically while a primary remains available to the backend.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100