How to cite?

[rnd0101]

This is probably a question, which can be answered somewhere in readme and closed:

what is the preferred way to cite Miser-project? (or maybe even different parts of it)

(Not that I personally need it immediately, but who knows when it will be needed)

Thanks for you great efforts!

[orcmid]

Good question. The Miser Project is the "official" site, but it is running far behind the discussion that is happening here using Question Issues and the text files of the mathematical formulation and the mockup-work.

Meanwhile, I suggest reference to internet-available materials by the master-branch URLs that GitHub provides. That informality will have to do until there is better collegial-scholarly structure :).

---

One bottleneck is the need to restore the Numbering Peano blog and also get to work on Miser Project web pages for preserving work developed experimentally here on GitHub. I will also have MathJax in the new blog, and that will assist presentation of mathematical material.

I am having a serious browser-/web-server compatibility issue at the moment, frustrating my experimental work-up of the replacement blog-publishing approach on the Spanner Wingnut Muddleware Lab. I am frustrated by the terrible failure of all versions of Internet Explorer from IE 8 to IE 11 to render those pages properly from that web site, even though everything works fine on node.js and localhost. Other browsers, including Edge and Chrome, work fine though. I must get back to that despite the work here on GitHub being so energizing. I have some ideas for the blog problem and isolation of the problem. Then maybe there will be a successful workaround and I can continue.

[rnd0101]

I've found one approach here: https://academia.stackexchange.com/questions/14010/how-do-you-cite-a-github-repository

And now I'm at last moved my material on Eternal to github: https://github.com/rnd0101/eternal , inspired by oMiser/oFrugal efforts here, so I also need to take a step back from oMiser and reflect. Many thanks for a possibility to explore your concept!

I was thinking to contribute here with a fork, but now I think it can make sense to make a separate repo for Python oMiser/oFrugal shell (the Coq, Antlr, RDF mockups are probably not worth to maintain - they are more like cursive writing worksheet from my early learning stage). Any ideas how / if you would like Python shell?

[band]

One current approach to citing a Github repository described here: "Making Your Code Citable".

It depends on using a Digital Object Identifier (DOI) and this involves using yet another repository for snapshots of the repo. I think this approach has support in the Scholarly Communication community of practice. But it does require maintenance of the Github links and may not be practicable for a fast changing project like Miser is now. Maybe just create a snapshot of the current state and describe it as an ongoing project?

[orcmid]

@band One current approach to citing a Github repository described here: "Making Your Code Citable".
...
it does require maintenance of the GitHub links and may not be practicable for a fast changing project like Miser is now. Maybe just create a snapshot of the current state and describe it as an ongoing project?

I see that the tie-in with Zenodo is predicated on the GitHub release mechanism. Thanks for that, @band. I had already used creating a digitally-signed labeled branch as a release binding for some early nfoTools at Adv10 work (misplaced under Adv10 and since refactored out - sheesh). I will see how that might be blended in when I do it correctly at nfoTools.

@rnd0101 I've found one approach here: https://academia.stackexchange.com/questions/14010/how-do-you-cite-a-github-repository

Deep in there, the GitHub-Zenobo arrangement is mentioned. That seems preferable since the favored approach involves creation of a paper about the software and having it published by the Journal of Open Research Software. I suppose that oMiser qualifies as software for research but this seems a bit roundabout (and not free).

One thing I think it is important to distinguish is citation of work in progress versus citation of a stable fixed artifact, just like the authoritative source of a scientific/scholarly paper. I suggest that specific, stable citations be tied to fixed (i.e., signed-label) release branches. For work-in-progress, I think the best that can be done is citation to/into master.

PS: Another consideration to ponder is when something is a suite, and not a single all-or-nothing deliverable. I think this should work when components of a suite project are released, without making separate GitHubs. That is my hope 😉 .

[orcmid]

@rnd0101 I was thinking to contribute here with a fork, but now I think it can make sense to make a separate repo for Python oMiser/oFrugal shell
...
Any ideas how / if you would like Python shell?

A pull request of the Python shell mockup would be appropriate at some point.

I don't think it is ready at this point because we have not converged on the REPL process. I see Questions #7 and #10 still require sorting out.

I suggest leaving the Python shell approach where it is. You might want to refine it some point and either way I can submit patches and/or cherry-pick it later. If you prefer to submit a pull request, I will be happy to cherry-pick the Python shell into orcmid/miser/oMiser/mockups to preserve it for further refinement.

However you choose to proceed, I will be gladly acknowledge your valuable contribution, @rnd0101. Your explorations and questions have triggered rapid advance achieved in the past couple of weeks.