The Maneage, Elaphrocentre and Subpoisson papers are all now accepted by their respective journals, CiSE, MNRAS and PeerJ; Maneage and Elaphrocentre are formally published, Subpoisson is still going through proofreading and so on.

A discussion started with this merge request https://gitlab.com/maneage/project-dev/-/merge_requests/7 about how we can allow frequent updates of Maneage'd papers and their publication status without distracting people who want to keep their project updated for software reasons. Currently, we have both:

• README-hacking.md is one place where we list these articles; and
• https://maneage.org/about-citation.html - source at https://gitlab.com/maneage/webpage/-/blob/master/about-citation.html .

It seems reasonable to me that for the moment we allow frequent updates of the webpage list, and just do updates of README-hacking.md once in six months or so.

However, we need to have something more bibtex|yaml|jason -like, or even better, something consistent with the Maneage criteria: a conf style convention and a 'make' file to extract the info in html format for about-citation.html, and in plain text for README-hacking.md .

Of course, once we get to say, 20 papers or so, we'll probably want to split off the web text to its own separate page, and this will start looking excessive for README-hacking.md. We currently have 8 papers, 3 of which are clearly branded "Maneage" in the article pdf.

The elaphrocentre paper is submitted and archived and git-archived :). I've updated the publication list in README-hacking.md on maneage_dev:

https://codeberg.org/boud/maneage_dev/commit/ea7eddc399335a982e194ed10abe5d13d8d0ee42

In case anyone missed it, MNRAS now has a formal requirement to include a Data Availability Statement at the end of any paper, and there's an informal request to document software availability:

https://academic.oup.com/mnras/pages/General_Instructions#2.9%20Data%20Policy

Handling these should be straightforward for any Maneaged paper.

Obviously, it's up to the editor and referee to decide how seriously to take the statements, and up to the community more broadly to decide if it accepts formal statements that more or less say "We couldn't care less. You may beg us for the code if you really think you need it." Let's hope that we raise the standard. :)

Thanks for the congrats :).

Regarding the last-common-commit-with-maneage , it's true that people could update and not think of updating the metadata. Maybe we could name the parameter something like "last claimed common commit" rather than listing no known common commit at all? Though I guess that something automatic will probably make more sense in the longer term. It should be easy, though maybe not trivial.

My guess is that a script to do this automatically would have to use diff or one of the variants. I recently found that dwdiff can handle big (100k) text (log) files reasonably while wdiff took 20-30 seconds and I ctrl-C'ed it rather than waiting longer.

I'm not so sure how correctly a diff program would correctly find the most recent common ancestor. Someone should write a script and try... :)

Thanks a lot Boud, I just pushed it as [git.maneage.org/project.git/commit/?id=b3d8fea7010e Commit b3d8fea7010e].

I just removed the last maneage commit from the end of each item. I initially thought it is a good idea too, but the projects can get updated and if they do, we may forget to update it here and there will be confusion. People can always check from the project's Git repository (which we link to) ;-).

Done - I had forgotten that that list was there :)  It's more complete than the list I posted here, though not quite so parseable.

https://codeberg.org/boud/maneage_dev/commits/branch/update_papers_list

https://codeberg.org/boud/maneage_dev/commit/113648627569e535367f3c6b95a073814021e647

https://codeberg.org/boud/maneage_dev/commit/179502572b21143a319f2c77431c77c3a7d684e1

Feel free to squash these together as a single commit.

Raul: sorry about confusing your given name and surname in my first post to this task! :)

I propose for the moment that we start off the Maneage paper list here in plain text - once there are enough papers we could put them in a .bib file and/or some other reasonable format (e.g. a make configure file :)) in one of the maneage-related git repositories. Or even a new repository, with a name such as maneage-bibliometry .

I've put these including the full URLs, though obviously, URL bases and URL IDs should be separated.

I didn't include the papers where part of the paper is in early versions of the reproduce format.

published-commit is not going to be 100% true - journals normally add proofreading changes and will not update the commit string.

key = Roukema2020
arXiv = https://arxiv.org/abs/2007.11779
git = https://codeberg.org/boud/subpoisson
zenodo = https://zenodo.org/record/3951152
swh = https://archive.softwareheritage.org/swh:1:dir:fcc9d6b111e319e51af88502fe6b233dc78d5166
published-commit =
submitted-commit = 252cf1c
last-common-commit-with-maneage = 25b6fcc
published-doi =

key = Akhlaghi+2020
arXiv = https://arxiv.org/abs/2006.03018
git = https://gitlab.com/makhlaghi/maneage-paper
zenodo = https://zenodo.org/record/3872248
swh =
published-commit = cd47aa9
last-common-commit-with-maneage = db31bce
published-doi =

key = Raul+2020
arXiv = https://arxiv.org/abs/1911.01430
git = https://gitlab.com/infantesainz/sdss-extended-psfs-paper
zenodo = https://zenodo.org/record/3524937
published-commit = 62d83df
last-common-commit-with-maneage = e376731
published-doi = 10.1093/mnras/stz3111

key = Akhlaghi+2015
arXiv = https://arxiv.org/abs/1505.01664
git = https://gitlab.com/makhlaghi/NoiseChisel-paper
last-common-commit-with-maneage = N/A
published-doi = 10.1088/0067-0049/220/1/1