Sorry if this report feels ranty. I did not bother to take the time to separate each issue into it's own bug report or feature request. It also looks like I may have done the functional review while there are still some pending fixes happening from earlier feedback by Taavi.

1. As I have reported in various ways previously, the UI of Bitu feels barren. There is no color; no branding; no obvious navigation affordances; no link to privacy policy, terms of use, code of conduct for technical spaces, etc.
2. There is no indication on the ssh key upload form what fields are required
   • It turns out that both the "Comment" and "Ssh public key" fields are required, even if the provided key contains an embedded comment.
   • T359535: Autofill key comment from filled key itself
3. There is no indication of what types of ssh keys are supported or hints about what an ssh public key might look like. Experience in tech support here tells me that many technical volunteers need some hints about such things.
4. Once the upload form is submitted the user is returned to the https://idm.wikimedia.org/keymanagement/ with no indication that the operation succeeded or failed.
5. Upon carefully reviewing the list of keys one might notice that there is a new entry at the bottom of the list which looks slightly different than the others (if there are others for comparison). The difference is a pair of "Activate" and "Delete" buttons. The "Activate" button apparently must be clicked to trigger Bitu actually changing the LDAP directory contents rather than just some local database. This information could have been provided on the upload screen ("Note: you will need to activate the new key...") or in a success toast shown after the upload.
6. On the activation screen there is a "System" dropdown that only has one option, and also has no explanation of it's purpose. I assume that there is some future functionality planned that would allow selecting a different "System" for the key to be used with, but if I was a typical Wikimedia technical volunteer why would I care? This option should be hidden until there is actually a use for it.
7. Once the activation form is submitted the user is again returned to https://idm.wikimedia.org/keymanagement/ with no notification toast of any kind telling them that the operation succeeded. Again they are expected to review the list of possibly dozens of keys to find the one they think they just activated so they can see if the "Activate" and "Delete" buttons have now changed to "Suspend".
8. Attempting to use the newly added key immediately does not work. Is this because there is some unknown (unknowable?) amount of lag between the LDAP primary and the read-only replicas used in the WMCS environment? I have been hitting refresh on a query of the ldap://ldap-ro.eqiad.wikimedia.org:389 for more than 5 minutes and the key I added still has not shown up. At this point I'm not sure if this is replication lag or a sign that some queued job to actually update the LDAP directory has failed or gotten stuck in the queue.
9. I reload the https://idm.wikimedia.org/keymanagement/ page, and the new key I had attempted to activate is showing the "Activate" and "Delete" buttons again instead of the "Suspend" button. This maybe is supposed to tell me something went wrong with the activation process? Does the local storage in Bitu know that I tried to activate this key? There is no error message to make that clear if so.
10. I change my mind and decide to delete the problematic key. I see what looks like a typo of "Suspend key key" on the deletion screen.
11. Having had poor luck adding my new key via Bitu, I decide to use Striker instead.
    • The form gives me hints about what a public key string starts with.
    • Upon submission there is a success toast message telling me the key has been added.
    • The new key is shown at the top of the list rather than the bottom which makes it easier to spot. (This might be accidental? I'm not sure if there is a consistent ordering, but it does look like the last in, first out ordering is also seen in the LDAP directory.)
    • The key shows up in the LDAP directory and my Wikitech preferences in less than 60 seconds. (So there probably was some hidden failure in Bitu that made things not work as expected.)
    • Bitu still can't see my new key after reloading the https://idm.wikimedia.org/keymanagement/ screen
      • A full logout/login cycle makes the new key show up in Bitu which is not the worst thing ever, but not completely obvious.
      • T360634: Bitu not importing key changes directly in LDAP