Currently there is no to change mentor settings (such as the primary and fallback mentor) of the user without having some low-level access, such as direct production DB access. It's bad form in general to deploy a feature that assigns work to volunteers but does not give them any control over the details of how that assignment is done.

There are various plans for adding user interfaces in the GrowthExperiments extension for controlling mentor workflows (see T239234: [EPIC] Newcomer homepage: Mentorship dashboard), but those take non-trivial effort, and it's hard to predict in advance how useful they are going to be, so they have been prioritized down. But we should at least add the infrastructure for allowing external tools to be built for mentor management; that's fairly easy and effectively outsources the design/experimentation work of figuring out what functionality is useful. (See also the second architecture principle.)

This would take the form of a new editmentoroptions user right which allows users to edit mentor-related user options of another user (the extension would include a whitelist of what options those are exactly; at this time, growthexperiments-mentor-id and maybe growthexperiments-mentor-questions in readonly mode for monitoring response times), and a simple ApiOptions-like API for reading/writing those options. Communities could easily build gadget, bot or OAuth based tooling around that.

Currently, these settings are editable by the owner only; this would further expose them to a small set of highly trusted users. Things to consider:

• security; if some setting values are output as unescaped HTML, users with this permission could perform XSS attacks. (For SQL injection or RCE attacks, it does not make much difference whether it is the owner or someone else who can perform them.) Highly trusted users can already perform XSS attacks in a number of ways so this is not really an issue.
• robustness: the software would have to assume that all these settings are user input, containing potentially invalid data. (Technically this is already the case since the owner can already write these settings, but there is no reason anyone would do that.) As long as the relevant options are simple strings which are validated by MediaWiki internals (e.g. User::newFromText) this is not much of an issue.
• privacy: we'd have to ensure the settings that are made available don't contain anything for which the user has a reasonable expectation of privacy (e.g. never expose welcome survey data this way). Again, not a problem for the core use cases.