(no commit message)
authordaven.quinn@d0ed4e0e5e4462d9a74a5d5a8fbd1b17f85db13e <davenquinn@web>
Tue, 19 Jul 2022 07:57:37 +0000 (07:57 +0000)
committeradmin <admin@branchable.com>
Tue, 19 Jul 2022 07:57:37 +0000 (07:57 +0000)
doc/todo/Usability_improvements_for_new_users.mdwn [new file with mode: 0644]

diff --git a/doc/todo/Usability_improvements_for_new_users.mdwn b/doc/todo/Usability_improvements_for_new_users.mdwn
new file mode 100644 (file)
index 0000000..5935bbf
--- /dev/null
@@ -0,0 +1,18 @@
+Hi there,
+
+I'm a relatively new to `git-annex` and quite impressed so far.
+
+I've found the command to be somewhat less self-documenting than I'd like it to be for a new user.
+Particularly, since it's a `git` subcommand, I'd wish for annex to 'mirror' as many subcommands as possible
+with `annex`-enabled equivalents. My chief complaint at the moment is that it is a bit hard to remember the
+specific commands for showing remotes (`git annex info` has no equivalent `git info`) and `git annex remote`
+should ideally return a list of remotes for parallelism.
+
+Similarly, it'd be nice if some of the commands were a bit nested to match `git` semantics. This would increase discoverability:
+For instance, `git annex enableremote` -> `git annex remote enable` or `git annex renameremote -> git annex remote rename`. Then subcommands for dealing with remotes
+could be more easily summarized on a single page in the `git-annex-remote` section.
+
+It's worth noting that such changes could happen alongside the current commands without a loss of functionality. Git core
+has recently gone through a similar process to simplify the semantics of some of its commands. I'd ask for such changes to be considered.
+
+Daven