Latex template files for authors
scfrank opened this issue · 24 comments
This repository is now the canonical place to download the latex and word templates for ARR, if one doesn't want to use Overleaf. And then Github makes it just awkward enough to download the multiple files in templates/latex that it's easier to clone the full repository. However, this repo isn't made for author end-users either:
- The repository is really bloated if you're looking for just the latex templates - the full repository is 23MB, 13MB of which is in .git/ and 5.5MB is in templates/archive. (I know this is very old-man-yells-at-cloud in this age of terabytes but still - this doesn't need to be replicated across tens of thousands of directories.)
- Most of the information (e.g. in docs/) is clearly for publication chairs, not authors.
Maybe ARR could offer tar bundles for the templates again? Or this repo could also contain tar bundles of the files in templates/latex, so it would be possible for authors to just download the single file?
Thank you for considering this.
I've forgotten why we decided to keep all the Softconf stuff and the templates in the same repo, but it does make sense to me that the templates should be their own repo. @mjpost
We pull everything from the "start" branch, which should be a duplicate of the master, but serves to let us update the repo with bug patches we find. Then we merge if there are no conflicts.
The templates should be identical to those in the master. I wasn't aware that you had authors cloning the entire ACLPUB repo, but if so, you should really make a (much smaller) branch just for them.
I think @davidweichiang is referring to the paper templates, rather than the templates used to assemble the proceedings. I agree that that former would best be placed in its own repo. We could publish releases that would then be easily downloadable.
Right. So what would be the smoothest way to do this?
- Which piece should move and which should stay?
- What should the new repo be called?
- Who has to be informed about the new URL?
- What kind of pointer can be left at the old URL?
- Can we do this in the next couple of days, since a deadline has just passed and 1/15 will be another big one for NAACL?
Which piece should move
What kind of pointer
I think everything in templates/{latex,word,archive} should be extracted. We can leave a README there informing of the move.
What to call it
I suggest we create acl-org/acl-templates, but maybe you have better ideas.
Who has to be informed
ARR at least (they link to us from here). But they link to the directory, so a README with the updated link should be a big help. We can also get them to update their link.
Next few days
It doesn’t seem like that much work, mainly updating documentation that is under our control with the updated links.
How about preserving the history? Is that possible?
seems like yes: https://ao.ms/how-to-split-a-subdirectory-to-a-new-git-repository-and-keep-the-history/
just a thought, but maybe we could set up a github action to post a tar of the style files,
without creating a separate repository.
https://docs.github.com/en/actions/publishing-packages/about-packaging-with-github-actions
To avoid further confusion about paper templates vs proceedings templates, how about let's call the new repo acl-paper-templates or acl-style-files.
@danielgildea that sounds good too, but I find that the issues & PRs all cleanly fall into one category or the other, yet it's hard to tell from the title which category it falls into. So I think a split would be a good idea in any case.
@danielgildea that sounds good too, but I find that the issues & PRs all cleanly fall into one category or the other, yet it's hard to tell from the title which category it falls into. So I think a split would be a good idea in any case.
ok!
I vote for acl-style-files. Let me set this up a sec.
I have to get back to other things but can try to clean up the documentation later tonight or tomorrow.
For a cleaner split, I think it would have been nicer to git mv the unwanted stuff out before doing the git filter-branch, rather than git filter-branch then git rm.
I redid it and force-pushed. However, since the rms are part of the templates/ subdir, that part of the cleanup will be in the commit history, unless there is a fancier argument to git filter-history that lets you pick just subdirs of a subdir. The project is fresh so feel free to force push if you want to take a stab.
Actually, it looks like I really screwed this up. I force-pushed to ACLPUB, instead of to acl-style-files. Anyone have a fresh copy of ACLPUB that they could force-push back?
After that we should disable force-pushing to master.
The start branch is more up to date than what I have on my machine.
I just restored the start branch to master, but it doesn’t have the most two recent PRs that @davidweichiang just merged, #64 and #65. David, I’m hoping you have a local clone.
The
startbranch is more up to date than what I have on my machine.
Okay. The recent two merges are relevant to acl-style-files, though, so maybe it doesn’t matter, since we’ll be cleaning that out of here, anyway.
@rrgerber, can you check if you have a local clone of ACLPUB with a more updated master branch? Perhaps the one I just restored is the latest.
I just re-did my two most recent PRs.
@rrgerber, can you check if you have a local clone of ACLPUB with a more updated master branch? Perhaps the one I just restored is the latest.
We just pull from the start branch, and I don't have any local clones of master.
When you are done sorting this out, I will pull from the master again to resync the start branch.
I pushed to acl-style-files with a history that doesn't have anything about proceedings or copyright in it.
@mjpost I don't want to cross the streams, so I will pause from doing anything right now. I think the remaining tasks are:
- remove templates/{latex,word,archive} from this repo
- rewrite templates/README.md in this repo to point to the new repo and accurately explain what is still here
- update the README.md in the new repo to be a little more explanatory, and to change the issues at the bottom into Github issues