paper narrative

[jovo]

the paper is currently written like a "how to" manual that one might get from ikea.
it is very easy to read, but not exactly what technical journals want.
after figuring out very carefully what is the main gap that we are filling,
i think the following organization would be a big improvement

1. a "methods" section, including how to (in general)
   a. organize data into standard specification,
   b. get data online,
   c. put code in virtual machine,
   d. get VM in cloud,
   e. run on data
   f. store derivatives in standard spec.

imagine a paragraph describing each of those steps, plus a figure/panel demonstrating each "in general".

1. the main usecase: sic:ndmg.
   which explains the choices we made for each step (BIDS, S3, docker, EC2, etc.)
   (again, a figure making each decision clear), and why.

why BIDS vs something else?
why S3 vs Google vs etc...

1. extensions
   a. replace data with different data
   b. replace some code with different code
   c. update docker
   d. add analyses

(again, a figure showing the impact of each decision, eg, when replacing data, showing the results change, when updating code, results change, changing algorithm, results change, add analysis, results change, etc.)

1. discussion points out that this sic framework can be applied quite widely, and how it can be imrpoved (1 click auto-launch of stuff), etc.

i'm not sure whether 1&2 are completely seperable, and i'm not sure whether we need 3 to get the paper into gigascience.

i am sure that the way it is currently written will raise eyebrows.
the thing that will be most difficult about this paper is that it is already so far from what people expect, we want the structure to be as familiar as possible, so they can really focus their cognitive energy on the contents, rather than the structure/tone.

right not, structure, tone, and contents are all unfamiliar. let's get only 1 of them unfamiliar (contents)?

[gkiar]

👍