Repository navigation
Log of ongoing project #2
Description
Does anyone know of a good way to share online a running log of simulation results of a shared ongoing project? This could be a way to share current results and also log methods that have been tried and failed.
This is can be done in github if we want to share only text, but if we want to include output plots and images, I don't know if this is the right platform.
Thoughts?
Activity
lederman commentedon Jun 14, 2017
I don't think we need a strict rule for now. We can experiment with a few ideas and decide what works best for the next project. We should just use some judgement, and if we feel that things are getting out of control we should talk and do some reorganization.
I think we should each take ownership on the projects we start - we can use the project I started as a place to play with different ideas and when I feel it is getting out of control I'll organize it a bit.
More specifically:
I think that we would ideally want the most interesting stuff merged back to the master branch, or branched to a separate repo. It can be in the main/src folder, or a subfolder if there are a lot of specific files. That said, too many experiments may cause clutter.
I suggest that we write informal reports that would basically be partial logs and figures. Ideally, the reports would reference a code that we can run at any time. But, to avoid clutter, we can also reference certain commits in any branch that is pushed back to github with the commit date and link, e.g. your GeometryOfData/2017_04_DeepTensor@0f7e9a5 .
There are two places we can store these reports: main/reports , or with the code in the main/src folder or subfolder. I think that if you have enough code to justify opening a folder under /src, you might as well store the report with it. Otherwise, if this is a short report, we can store it in /reports.
We can try this and decide what works for us best.
The important thing is to write a short "abstract" of what you did, mentioning where the code can be found. I think that it is best to put this abstract in the readme.md file of the project (e.g. https://github.com/GeometryOfData/2017_04_DeepTensor/blob/master/README.md ). When this grows out of control we'll make a separate file.
Perhaps we should consider using Jupyter Notebooks for some code, because it allows you to write code that looks kind of like a report. It's just a thought, I'm not sure I'd like to set this as a standard.
lederman commentedon Jun 14, 2017
I'm thinking as I'm writing this.... using the "issues" in each project as a place to write a report? I'm not sure that it is portable, but it can be a convenient way or writing reports... thoughts on this?
gmishne commentedon Jun 20, 2017
What about the wiki of each project? wouldn't that make more sense? I see you can add images there and it says:
Wikis provide a place in your repository to lay out the roadmap of your project, show the current status, and document software better, together.
Then maybe each sub-project or user(s) can add a page of their own to document where they are with the project.
lederman commentedon Jun 22, 2017
It is definitely the "correct" tool. It has plenty of advantages. However, I am worried that it might take a little more effort to write a wiki page, and you have to know that you should go to the wiki.
I'm in favor of trying what you are comfortable with even if this project gets a bit messy. It's just the first project, let's experiment.
I think that we should put some links in the readme file to the wiki pages, so people don't have to proactively go to the wiki.
BTW: do updates to the wiki show up in the feed? When I updated the wiki, did you get a notification?