Figure selection

[mih]

According to https://joss.readthedocs.io/en/latest/submitting.html#submission-requirements:

Your paper (paper.md and BibTeX files, plus any figures) must be hosted in a Git-based repository together with your software (although they may be in a short-lived branch which is never merged with the default).

that means we do not have to suffer from a complex, heavy image file in the main repo. Hence I propose to not go for a figure that is not minimized for size. Moreover, it should also not be imaging specific, but still sciency. I propose this one as a starting point:

[yarikoptic]

I propose the one (or an updated version of) of what we have ATM

since it would provide a very nice and concise depiction of "actionable" functionality.

PS I think it is totally ok to have 2 or 3 figures

[mih]

Ok, so here is an updated and extended version of this figure:

Key changes

• updated to reflect the current API
• de-emphasized the role of metadata, in particular its representation within a dataset
• give examples of extensions without going into details

[yarikoptic]

nice! I would have liked to keep install but I will not fight that.
can we still fit get somewhere? IMHO it is more important than copy-file

[yarikoptic]

@mih could you please upload .svg of this extended figure ? we are yet to add (or displace copy-file) get.

Actually save should also get from External resources, and that might be a good "section" for copy-file if desired to keep it?

[mih]

nice! I would have liked to keep install but I will not fight that.

Thx

can we still fit get somewhere? IMHO it is more important than copy-file

We can replace copy-file with get from my POV.

@mih could you please upload .svg of this extended figure ? we are yet to add (or displace copy-file) get.

Upload is done. I can edit later, once a conclusion is reached.

Actually save should also get from External resources, and that might be a good "section" for copy-file if desired to keep it?

I am not sure what you refer to with "save should also get from external". I placed it under "external" because it is the primary way to put non-datalad-racked content into datalad. There are a few exceptions, but in general this is the main entrypoint.

[yarikoptic]

I am not sure what you refer to with "save should also get from external".

that it should not be listed among "External resources"

I placed it under "external" because it is the primary way to put non-datalad-racked content into datalad. There are a few exceptions, but in general this is the main entrypoint.

it is also the way to save all local changes etc, unless we consider a "human operator mind" to be an "external resource". But if we do such a stretch, then all commands qualify "external resources" . Also since it operates on content in the tree (not some remote path, url etc) I feel that it is also a stretch for "external" in that aspect too. Even clone is more "external" than save in my mind. If we do want to keep separation from "External resources" and keep number of items, what about

• DataLad
  • create
  • clone
  • run/rerun
  • save
• External resources
  • addurls
  • get

But I think we might better just dissolve that difference (some group-vs-External resources) since that is the point somewhat to not care about that - datalad and git-annex help to make external resources look like "part of it", or keep it only for the right outgoing export-* although even there it is already a bit of stretch since e.g. export-to-figshare annotates annex back with url to figshare. And hopefully eventually would do the same what datalad-osf does by providing full git history etc.

Also update on the right is odd since we are not pushing updates, we are fetching them, I would just remove it to avoid confusion. In the caption we should just say that it is just some of the commands, and refer to the cheatsheet for a more exhaustive list.

[mih]

Sounds like the figure needs a major update, and I am not qualified to perform it.

[yarikoptic]

Seems selection was made. I don't think it is worth keeping this particular issue open