Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manage HGmodelManuscript folder #15

Open
3 of 4 tasks
HubLot opened this issue Mar 23, 2015 · 5 comments
Open
3 of 4 tasks

Manage HGmodelManuscript folder #15

HubLot opened this issue Mar 23, 2015 · 5 comments

Comments

@HubLot
Copy link
Member

HubLot commented Mar 23, 2015

It would be great to clean up & re-organize this folder. For the moment, it's quite hard to figure out what are the versions of the manuscript, which figures are used, etc.

Here, some thoughts to improve it:

  • Remove all temporay latex files (*.log, *.aux, *.bbl, *.blg): Tracking these files are not really relevant and with now with the .gitignore, they are discarded.
    At the end, only *.tex, *.bib and *.pdf will be tracked, it will be less confusing.
    See 8d5238b e391494 4672afb e262449 0cb076d
  • Remove old versions of the manuscript: again to avoid confusion, we should keep only the JACS version (HGmodel_ACStemplate.tex) and the arXiv version.
    For now, we have HGmodel_draft3.* and HGmodel_draft3_matti.* (and the latexdiff) but I don't know if they are still used. Is draft3 correspond to the arXiv version ?
    See 59d0fbc 3d6447c
  • Manage figures: ~~it's the tricky part. For now, it's difficult to know which figures are the good ones and how they have been created. I don't have the best solution in mind but maybe:~~See Repository Organization #17
    • Keep the figures in separate sub-folder (a global one or one for each figure)
    • Provide the script to recreate the figure from the data (see dehydration.pdf and cholesterolization.pdf #6).
    • Move the figure files to the Fig folder.
    • The list of the figure used in the manuscript should appear in the README
  • Improve documentation: Improve the README to help people understand the organization.

Let me know what you think

@HubLot
Copy link
Member Author

HubLot commented Mar 24, 2015

About the figures part, a more viable solution could be to have one global folder "fig" at the root of this repository. Inside, we could have a Makefile to properly generate the figures and a sub-folder "scripts" where the scripts used will be stored.
For the manuscripts, we will use those \includegraphics{../fig/myfancyfig.eps} and describe in the README where we can find them.
In this way, they're is no duplicate and the folder "HGmodel_manuscript" will contain only the needed files.

@ohsOllila
Copy link
Member

I think that cleaning and reorganization is necessary (not only for this folder but also for the whole repository). Also, it would be useful to find the most practical ways to do this since also other publications will be written like this, at least the lipid-ion interaction manuscript in the LIPIDionINTERACT folder. In addition, I have already created another repository for the new project where also x-ray data would be included: https://github.com/NMRLipids/NmrLipidsCholXray. In that project the GitHub will be used from the beginning so it will have a bigger role.

Regarding this issue, I have now removed temporary latex files.

I also created a separate folder where I put the old versions. None of these old versions are used anymore, however I wanted to keep them visible. I have changed the file name, when the todo list numbering has changed. HGmode_draft3* is newer than arXiv version. This is little bit messy now also because this was put into GitHub in the middle of the process, not from the beginning. When we do it from the beginning, we have to think how to keep better track on different versions and todo list numbering.

I think that your suggestion for the figures sounds good. We could start to go to that direction, however, I did not do anything it yet. Also in this case, not using GitHub from the beginning complicates this little bit. If you can figure out enough about the figures and files you can start to do this. I will try to progress this as well, and in other publications I will try to do this from the beginning.

Improving the documentation is also extremely useful. The description you did for this folder is, however, the best in this repository. So there is more work in other folders.

@HubLot
Copy link
Member Author

HubLot commented Mar 24, 2015

Indeed, the lipid-ion manuscript can benefit all improvements made here.
Regarding the whole repository, I have also a couple thoughts (about data, input files, documentation, etc) to improve it (I'll make a separate issue).

Thanks for cleaning up the folder and move the old versions. I'll start working on the figure management and make pull-requests.

I agree not using github from the beginning complicate a little bit this but it's a "work in progress". To keep track on the todo list, maybe the easiest way is to use the github issues as a todo list (see here).

@ohsOllila
Copy link
Member

Issues as a todo list is very good, I think. However, I would like to have todo flags also in the manuscript. The reason is that we have been used to handle this kind of information in a manuscript format, so probably the best way to get the general picture about the project status is to read the manuscript, even though it would be very preliminary. For this reason it would be very useful to mark places which needs work with some todo flag. Maybe these kind of flags could nicely linked into the issues?

Related to this, I think that in the future projects we should have the manuscript assembly going on all the time with the todo flags, even from the very beginning of the project. The first projects were done such that, in the beginning there was the manuscript, then we used blog, and in the end we moved the blog content back to the manuscripts. It may be easier to have manuscript updating all the time, have data in GitHub and discussion in issues and/or blog (or similar).

@HubLot
Copy link
Member Author

HubLot commented Mar 26, 2015

Yes, in my mind, I thought to have both: the issues and todo flags in the manuscript because, it will be easier for non Github users to keep the latter. To sync the both, I don't have a solution but maybe doing it manually with a reference name (since the number of flags will keep changing over the versions).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants