| Age | Commit message (Collapse) | Author | Lines |
|---|
|
In this commit, the URLs for the 19 "earlier solutions" at the
beginning of "3 Principles" are recovered from
tex/src/paper-long.tex and put behind the package names
as clickable words.
To reduce the chance that these are interpreted as references,
"Project1 (yyy1), Project2 (yyy1)" is changed to "yyy1: Project1,
Project2". We cannot add full references because of the 8000-word
space constraint.
With a minor word improvement, this commit overall reduces the word
count very slightly, by 9, according to
pdftotext paper.pdf |wc paper.txt
before and after the commit.
|
|
Scalability is not just on the size of the project, but also its
complexity, so I added an `and/or complex' to the description of the
scalability principle.
|
|
Someone reading the principles section until now would think that IPOL is
an almosts perfect solution, and for its usecase it certainly is. However,
this is only because of the nature of its work: it only focuses on
algorithms, not usage/analysis which cannot be done in raw ISO C.
So with this commit, I added a new principle on Scalability and discussed
this limitation of IPOL there. To avoid simply lengthening the text, to add
this new principle, I had to remove/summarize some parts that seemed
redundant. In the process, I also removed some of the existing tools (at
the start of the principles section) that had several others in the same
time frame, I have already mentioned (through the "and many more") that
this list is not complete.
Also, the list of people to thank in the acknowledgments is now put in a
one-line per name to be more easily maintainable: Boud and Mohammad-reza
were added, and given that I have sent the paper to several other people
for feedback, I expect the list to get longer.
|
|
A few more minor language edits. For parseable vs parseable, see
https://en.wiktionary.org/wiki/parsable which recommends `parsable`
for formal usage.
|
|
These are mostly minor language edits. There is one significant fix: the
word `typically' in `a non-free software project typically' cannot be
distributed by the project. There is a whole range of licences between
strictly free software definition, strictly OSI open-source definition, and
fully closed source. For example, software with a no-commercial usage
licence (similar to CC-BY-NC) can be publicly redistributed on any server,
as long as there is no requirement of payment or no requirement of payment
that is "commercial" (according to lawyers' interpretation of when a
payment is commercial).
|
|
These are important aspects that are highly relevant to Maneage: its
philosophy (the former) and usability (the latter). To add them, I tried to
summarize some other parts of the paper.
|
|
Three such cases and they are fixed.
|
|
A few minor issues were found and fixed in the text. I also tried to
shorten it a little further.
|
|
I forgot to put these in the last commit! They are now implemented.
|
|
I had another look at the text and tried to summarize it a little more
while also fixing several typos that I had just discovered! In the process,
I noticed that we hadn't actually put a link to Maneage's main Git
repository! So we now have the URL as a `git clone' command.
Also, I thought that its better to show the `TARGETS.conf' file (which we
actually talk about) in the file architecture instead of `LOCAL.conf.in'
(which we don't talk about any more!).
Finally, to be more similar with DSJ, the bibliography is now in normal
font size, not footnotesize.
|
|
In the introduction I had mistakenly put "metadata" instead of "workflow",
its corrected with this commit.
|
|
Ryan O'Connor is from RDA and my principle contact for the grant. He also
kindly went over the first draft of the paper and gave useful and
encouraging comments.
|
|
This was only relevant for the submitted version, so I am committing it
until the next submission.
|
|
After the submission and reading through the text another time I found some
typo corrections and fixed them. Also now that David is an author, I
removed him from the people to acknowledge (David brought this up himself,
thanks David ;-)).
|
|
Since the journal doesn't accept supplementary files during initial
submission, I have put this link on the PDF for the referee and editors to
access if they want.
Also the `tex/img' file was added to the distribution tarball.
|
|
Thanks David ;-)! I tried to implement as many as I could. For the time
being, I just removed teh `~' between "Section" and its number, and removed
the italics on software names. Let's see what the journal editors say about
it. Otherwise, most of the suggestions were very good and indeed made the
text much better to read.
|
|
David submitted these comments by email, I (Mohammad) am committing it into
the project.
|
|
To make the text easier to read and further comply with the author
guideline, the text was shrank a little more and the two final sections
were also added on "Competing interest" and "Author contributions".
I also found the CODATA logo on Wikipedia in SVG format (vector graphics),
so I replaced the previous pixelated PNG format with the PDF (converted
from SVG).
|
|
I removed the part emphasizing one journal, but about the comment at the
end of the conclusion (to say some negative things): we have already done
that in the discussion, mentioning the caveats ;-). But you are right, we
should summarize the caveats is well.
|
|
With this commit, minor typos have been fixed from Section 4 to 6. The
majority of them are minor corrections (typos/spelling). I added just a
couple of comments/suggestions in red. If you think they are necessary
try to fit with the latest modifications. If not, just ignore them.
Really nice paper, congratulations to all contributors!!
|
|
With this commit, just minor typos have been fixed (I am rushing over
the text since we are out of time!). There are also a suggestion in
order to remove a couple of phrases to try to be more aseptic when
comparing with another project. But there is only an idea, take it or
not as you consider.
|
|
A first draft for these was added and will probably become much better in
the next few iterations.
|
|
I went through the whole paper and tried to decrease its size even futher,
also a first draft of the summarized discussion has been added.
|
|
TeXLive recently transitioned from its 2019 version to its 2020 version
thanks to Elham Saremi's trial of the this project. The fact that
traditionally Maneage installs all TeXLive packages in a per-year directory
is very annoying and required an update in the core Maneage system every
year. So I suddently recognized that we can fix this by setting a different
name for the directory holding the release year. This has been implemented
with this commit.
I have also done this change in the main Maneage branch for other projects
to also benefit from this correction.
|
|
Thanks Roberto, they are now implemented.
|
|
I corrected bugs, typos, double words, and punctuations along the whole
text. I do some comments which are always highlighted with \hl{this is my
comment}, so you can identify them easily in the pdf. If you want to
remove, then you can do it easily with Ctrl+R since I think you never used
\hl. Finally, I added my name as coauthor but, please, feel free to remove
it if you want.
Note from Mohammad: since there were two other suggested commits before
this that were already merged, I rembased Roberto's commits and fixed a few
minor conflicts.
|
|
There weren't any conflicts in this merge.
|
|
With this commit, a short line telling that Maneage has tutorials
showing the workflow in a practical way has been added. Because of we
are near to the limit of words, I have added just a very short line. The
sentence does not specify any file name since the tutorial(s) is not
included (it will be in a near future).
|
|
With this commit, I have included a small line to recognize Julia
Aguilar-Cabello as the designer of the Maneage's logo.
|
|
|
|
The contents until two commits ago when I started to summarize the paper
are now in a new and shorter format: previously the discussion started on
page 25, but now it starts on page 17. It is still a little longer than
8000 words, but not as significantly as before. I will add the discussion
and also try to summarize it futher before submission.
|
|
As described in the previous commit, we had to shorten the paper to roughly
8000 words (which is significant decrease!). With this commit, I am
committing the current version of the summarized paper, where the
introduction, defintions and principles have now been summarized. I am now
summarizing the rest (describing Maneage and the discussion).
|
|
We just recently recognied that the final paper should not be longer than
8000 words. The easiest way was just to start a new `paper.tex' and bring
in parts from the original/long version. We can use all the hard work that
went into writing the long paper later (possibly in a manual for
Maneage). So I don't want to suddenly distroy its history at this point.
To let Git know about renaming the original `paper.tex' to
`tex/src/paper-long.tex', I am making this commit. This commit doesn't have
any `paper.tex' and only records the fact that it has been renamed. In the
next commit, I'll re-create `paper.tex' which will host the short/final
version. But thanks to this commit, if we later make any changes to long
version, Git will know that it was originally the main `paper.tex'.
|
|
Thank you very much guys :-).
|
|
I tried to get all the words I knew. Some may be correct in different
conventions. It definitely needs a second or third review for spell
checking.
Suggested some additional formatting, including but not limited to
using the LaTeX \textsuperscript{} command for stating dates.
Also, some unfamiliar rare words that finished with `-able` or
`-ability` may need to be changed. Finding better alternatives to
better simplify and ease the `readabiliy` ;-) of the paper - I see
it's hard not to use them actually. It has got me wondering what
better alternatives are available? We'll find out.
|
|
to shorten some sentences, fix some spelling/typos, and further
simplify some parts.
I can see that there are some spelling errors in the rest of the paper.
They will be taken care of in the next commit.
|
|
There was only a small conflict in the abstract with Zahra's corrections
and that has been fixed.
|
|
A parenthesis was added to the abstract to hightlight the importance of
data lineage for reproducibility. Also, the definitions that Zahra had
given for reproducibility were added as comments above the part on defining
reproducibility. We'll later decide how to blend them in, if possible.
|
|
With this commit, I have corrected several minor typos in Section 2
(Definitions). I have also put a couple of notes for modify or ignore
some phrases.
|
|
With this commit, minor typos have been corrected in the Introduction
section. The majority of them are just small corrections, others are in
order to not use contractions ("did not" instead of "didn't" and so on).
Other modifications have been added with the aim of remove some small
portion of the phrases to make it more focused.
|
|
With this commit, I have tried to make the Abstract a bit shorter. I
think it was too long considering that there are plenty of space in the
paper to describe some of the points that were noticed in the abstract.
The main point is just to try to be atractive to the reader being
focused to the main points. In any case I think there are room for
improving it. The keywords have also been sorted alphabetically.
|
|
With this commit, I have added my name as co-author of the paper. Since
my affiliation is the same as Mohammad's affiliations, I did not have to
add any additional line for that.
|
|
Because one of the most important properties of Manaege is
reproducibility. I think is it better to say something about it in the
abstract, like the thing that you do in your speech.
With this commit, I noted something about it in the abstract.
|
|
I hadn't updated the abstract since first writing it. With this commit, it
has been updated to be more precise and generically interesting, focusing
more on the principles and usability. I also greatly improved the section
on publishing the workflow.
|
|
This section (of sharing a build directory between multiple members of the
project) is also a good features of Maneage.
|
|
The figure was greatly improved, becoming much more clear and descriptive
of some of the main advantages of having version control in a complete
project like Maneage.
|
|
With the main structure of Maneage explained, I have started to explain how
a new project is created, along with a schematic diagram that shows two
scenarios of how Git can help with project management.
|
|
Until now, the introduction had repeated several things and also had a
relatively long list of things to add in its end. Also, it was highly
focused to scientific papers.
With this commit, I effectively re-wrote it, with the starting paragraphs
becoming more industry-friendly, while also focusing on the scientific
cases. Many of the repetative parts were removed and the listed items in
the end were put into the text in a much better context.
Also, now that the name of the system involves "lineage" (and a lot of
focus is put on it in the start) the terms data provenance and lineage were
defined in the definition section.
Some other intersting points that I encountered during the research on
definitions were added to the discussion and final lists, and the DOI of
one reference paper was corrected.
|
|
With this commit a description of these two important parts have been added
to the project, along with several figures showing various parts of the
files that are discussed. I also done some other restructuring of the
figures and files to make things fit better into the the description of the
paper.
|
|
Until now, I was mistakenly multiplying the fraction of papers in that
journal. This is corrected with this commit.
|
