--- /dev/null
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 2"
+ date="2024-02-06T16:10:56Z"
+ content="""
+To me, the purpose of any progress message is twofold: 1) let the user know the program is not stuck and 2) provide information about what was happening if it does get stuck. Push and pull do this now without JSON.
+
+I agree the same JSON progress object format should be used for all commands. Currently the action progress information includes: command, file, input, byte-progress, total-size, and percent-progress.
+
+The calling application is able to \"know\" which command it issued to cause the progress reports.
+
+A separate, optional field could be added for the particular remote involved. For example, messages like \"Copy file A to remote-one X% complete\" and \"Export file B to remote-two X% complete\" should be possible.
+
+I'm in favor of documenting data structures. Forcing developers to reverse-engineer the structure is inefficient at best. While the principle that all git-annex json output should be discoverable by simply running the command sounds good, I find it leaves much to be desired. Just to find out what's available, someone must setup and run the command. I suggest updating the requirement to \"All git-annex JSON output objects are documented.\"
+
+Users will get impatient and grow frustrated without some type of indication work is in progress.
+
+I'm OK with leaving Git operations silent for now.
+
+Please improve the end-user experience by devising a way to inform the user git-annex is making progress with JSON.
+"""]]