diff --git a/doc/todo/Usability_improvements_for_new_users/comment_2_ea77f0894802a17854aeedeceababf8a._comment b/doc/todo/Usability_improvements_for_new_users/comment_2_ea77f0894802a17854aeedeceababf8a._comment
new file mode 100644
index 0000000000..d7c2398dd7
--- /dev/null
+++ b/doc/todo/Usability_improvements_for_new_users/comment_2_ea77f0894802a17854aeedeceababf8a._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="daven.quinn@d0ed4e0e5e4462d9a74a5d5a8fbd1b17f85db13e"
+ nickname="daven.quinn"
+ avatar="http://cdn.libravatar.org/avatar/4811a26fff610f0c9668d183481a7158"
+ subject="comment 1 response"
+ date="2023-01-16T21:45:35Z"
+ content="""
+Fair enough, I suppose. However, I think that feedback from early-stage users should be weighted highly, as we interact with \"onboarding\"/\"discoverability\" problems that eventually fade from being users' primary impediments to use.
+
+> git-annex can't be limited to commands that happen to have equivalant git commands.
+
+I'm not suggesting that all commands should have `git` equivalents. Instead, when a commonly used equivalent (or close relative) is available, the name should be mirrored to increase discoverability of common idioms.
+
+
+> This would encourage drawing a false equivilance with git remote rename.
+
+I'm not quite sure why the equivalence would be false — yes, the commands do somewhat different things. But they both fundamentally rename a remote.
+
+> searching for strained equivilances to git remote commands.
+
+Again, I am not sure the equivalences are so strained. Users should not (and I think broadly won't) expect a git-annex subcommand to do exactly the same thing as a git equivalent. But semantic-level parallelism with git top-level commands, and adopting git's pattern of grouping like functionality into subcommands, could greatly improve discoverability. As it stands, the goals of *preventing confusion between similarly named functionality* and *allowing functionality to be easily found* are in tension. 
+
+Another way to frame my suggestion is to consider the layout of the `git-annex` command line help output. Right now, when seeking assistance, the user is presented with a long list of commands and has to hunt for related functionality (`renameremote`, `enableremote`, etc.) within it. In contrast, when I type `git remote --help`, I see all of the commands for managing remotes in a single, shorter output. It is another nesting level, true, but I think a help page entry of `remote - manages git-annex special remotes` would be easier to parse than the current output.
+
+Anyway, I appreciate your work on this system and consideration of user feedback.
+
+Regards,
+Daven
+"""]]