Replace Oobleck pdf with Arxiv

[insujang]

Remove Oobleck camera-ready PDF and replace it with Arxiv link.
Add an Oobleck ArXiv pub entry.

Note: just changing publist_link in .bib doesn't change a compiled publication page. Need to slightly adjust (e.g. removing The from any conference name) from publications/index.md to provoke a publication page recompile.

[mosharaf]

Hmm. I knew this is coming and we'll end up in a lengthy what-is-the-workflow discussion.

I was considering two choices.

1. Create an arxiv entry like we'd do any arxiv entry even though this will create two side-by-side entries in many cases; OR
2. we keep the local PDF but add a [arXiv] link to the arXiv to acknowledge it exists

I'm not sure if we should remove our PDF link.

[insujang]

I see. Let's talk in the group meeting :)

I personally prefer the second option, as if we have two entries for the same paper following the first choice, they might look detached and unrelated. But we might also need to talk about whether we should change all arXiv entries' [paper] link to [arXiv] or not. Currently they have a [paper] link connected to arxiv.org, but if we add [arXiv] only for papers, it would make some confusion.

Maybe making all [paper] links to the local PDF, and all [arXiv] links to arxiv.org would be better.

[jaywonchung]

I think this issue boils down to whether we want to view the publication list as a historical track record of our group's production of academic manuscripts, or a convenient list of each unique publication that does not necessarily reflect each paper's history.

This makes differences when a paper has a large time gap between its arXiv upload and actual publication. If we keep only one entry for each paper (the second view), the acceptance of a previously arXiv'ed paper will move its publication entry up to this year. Then years with particularly more number of arXiv uploads will get almost empty as those papers get into peer-reviewed venues, and it may mislead people to think that our group members have highly variable throughput, Mosharaf didn't care about the group on that year, etc.

Even without this practical disadvantage, I like the first view ("publication list as a historical track record of manuscripts") view better. It's like git commit histories.

[mosharaf]

I personally like option 1 more (as a commit history of everything that has been published even if it looks there are some quick repetitions like Oobleck).

I was offering option 2 ONLY for papers that are going to arxiv after acceptance. Papers that were in arxiv before acceptance (Auxo is a recent example) aren't affected.

To keep things consistent and simple, however, option 1 makes more sense as there is no special case. Anything published with or without peer reviewed just shows up as entries in the pub page.

[jaywonchung]

Coupled with the new all-papers-have-an-arXiv-version policy, this will lead to duplicate entries in the publication list. But that's probably fine. Doesn't hurt to ping people twice in Google Scholar Alerts. But we should make sure that the camera-ready version and the most recent arXiv version is identical.

[mosharaf]

Ideally, we should put on arxiv once the paper is accepted, then upload the CR to conference, and then come back to update the arxiv version with CR. This, however, will lead to stale versions as there will always be someone not as methodical in following the workflow.

So a more foolproof option is doing what we did with Oobleck. For first-time accepted papers, uploading to arxiv after CR. Even if someone forgets there is no inconsistent copies. This is consistent with whatever happening now.

In summary, "publish -> pub page. arxiv -> also pub page. No exceptions." This keeps everything simple with the only cost of having same thing appearing twice in our pub page every now and then (few papers get in the first time anyway)

[mosharaf]

LGTM. @jaywonchung ?

[insujang]

Having two entries per paper, the order is becoming more important, otherwise ArXiv papers will be at the bottom of the year publication list.

publist plugin seems to first sort with bib entry's year and month; if there is no month, it tries to use the conference's date. From now on all bib entries must have month.

[jaywonchung]

I think ideally @Aetf's publist plugin can support a publist_date entry with which it sorts publications in the list, but I think having month as a requirement is good enough for now.

[mosharaf]

@jaywonchung feel free to merge if there isn't anything. Thanks for your patience @insujang

[jaywonchung]

Shipping!

[Aetf]

I think ideally @Aetf's publist plugin can support a publist_date entry with which it sorts publications in the list, but I think having month as a requirement is good enough for now.

Noted :) Aetf/hexo-next-publist#38

[mosharaf]

I think #153 is the same issue