[ ] More consistent and comprehensible user messaging
[ ] Implement progress reporting
[ ] Robustify, decomplexify, and thoroughly document reconfiguration logic for remote access URLs. Currently there are url and push-url parameters, but insufficiently documented. It seems possible and advisable to migrate such configurations over to a (set of) "sameas" special remotes, one for each access mode -- rather than switching existing configurations. If auto-detection of connection/location is done, it should likely be done with yet another "sameas" remote in "private" mode, i.e. not committed in the git-annex branch (if that is possible). See https://github.com/datalad/datalad-ria/issues/30
[ ] Replace previous custom implementations for SSH-based remote operation (their main feature is download via a persistent remote shell to avoid offset cost on systems like JURECA where it takes 600ms to start a shell (even with a pre-authenticated connection)). Potentially switch to datalad-next's URLOperations
[ ] Honor server-side configurations and clean-up requirements (add shared access support, leave no cruft behind)
adswa
commented
1 year ago 
loj
[Taken from RFD]
urlandpush-urlparameters, but insufficiently documented. It seems possible and advisable to migrate such configurations over to a (set of) "sameas" special remotes, one for each access mode -- rather than switching existing configurations. If auto-detection of connection/location is done, it should likely be done with yet another "sameas" remote in "private" mode, i.e. not committed in thegit-annex branch(if that is possible). See https://github.com/datalad/datalad-ria/issues/30