Revise DataLad additions over git/git-annex section

[datalad]

Revise DataLad additions over git/git-annex section

[adswa]

I will try to implement the proposed structure

[yarikoptic]

Well, there are always multiple ways how to present an argument ;) And any of the dimensions to characterize against would not be totally orthogonal.

• current paragraphs in "Statement of need" for DataLad subsection serve as answers to "Why Git and git-annex alone are not enough" question which compliments "Why Git and git-annex". IMHO such formulation fits "Statement of need" section quite well. If to go for A-C I think then subsection names and wording within would need to be adjusted to reflect that new structure, or proposed A-C renamed to pretty much current ones (see mapping below) to reflect deficiencies we are addressing instead of strengths of DataLad.
• overall it boils down to mapping of 1 -> C, 3 -> A, 4 -> B with pretty much a complete removal of 5 (which I think would be a loss) and making 2 just a footnote of A.
• "Wider metadata support" ATM has little to nothing to do with B. Reproducible execution but already fits well with a distribution aspect. Thus if to be RFed into those 3, might better be hinted in "modular" (after all "aggregation" of metadata across subdatasets is a unique feature of DataLad here as well).

Overall, besides a possible "contraction", with just above description for the possible change I am not yet convinced that it would provide a clearer presentation of the "Statement of need" since it would pretty much boil down to loosing "distribution" and "best practices" arguments, and seems would require reshaping of the entire "Statement of need" presentation.

[mih]

We seem to have rather different views on what DataLad contributes in essence. I would prefer to have each point be a crisp declaration of an added value. However, neither of the five points (just looking at the tag lines) clicks with me. That may be just me. However, I don't think I am able to improve upon the present points.

[bpoldrack]

I lean towards @mih's view here.
A notion of "distribution" that would imply anything on top of git/git-annex has always been a very vague thing to me. As far as I consider it something valueable it is an emergent property from datalad's entirety that is shown best in usecases (esentially: handbook). 5 is vague thing to me, too.

For me it boils down to A, B, C. Possibly plus a clearer notion of "making git/git-annex easier to handle", which is somewhat hidden in A's seamless.

[yarikoptic]

"distribution" aspect is what started it all, and it is still there. Ok, let's sacrifice 5, and go with A(3), B(4), C(1), and move distribution (2) to 4 and see if it survives.

[mih]

As the OP, I think the manuscript has evolved in the spirit of this issue, hence it should be safe to close it.