acl-style-files
acl-style-files copied to clipboard
acl-org
Sync with Overleaf
Who maintains the Overleaf version and can keep it in sync with this version? @neubig @bethard @mjpost
The recent changes are not critical, but it would be good to know who to contact when there is a critical change.
Good question, I'm not sure. I'm not sure if tagging here will work, you might want to email.
It looks like @mjpost is the owner. Also, it appears that I can edit it -- I hope it's not world-editable -- is it?
Also, it looks to me like this is an ordinary project and not a template?
That is the draft template I created when we were fiddling around with the new environment. I did not realize this got converted into the official template!
I think it would be nice to create an Overleaf template that is linked to this GitHub repository. Then any updates here can be synced to Overleaf with one click.
Like this (demo, don't actually use): https://www.overleaf.com/read/yrqgpvyrscxj
- I don't have permissions to import from the real repo, so this is linked to my fork of it
- I don't know how to make this into a real template, and whether templates can be linked to GitHub repos
- Maybe
archiveshould be renamed to something later in the alphabet so it appears at the bottom of the file tree
@mjpost Do you know who we would contact in order to get permissions to import from this repo to Overleaf?
Someone made this on Dec 9: https://www.overleaf.com/latex/templates/acl-rolling-review-template/jxbhdzhmcpdm
Publishing a template requires moderation by Overleaf and I'm not sure what the process is for updating an existing template. Maybe it should remain an ordinary project after all. The only downside I see is that users have to take the extra step of cloning the project (which they currently have to do, and should be documented).
not only does publishing a template require Overleaf moderation, but then it's really really hard to get them to unpublish it. So I'd suggest not, thanks though!
OK, so I can think of two options:
(1) Continue using @mjpost's project and manually re-upload the style files whenever they change.
Pros: Status quo, simple
Cons: Re-uploading is more work
(2) Create a new Overleaf project (not template) that is set up to sync with this repository.
Pros: Syncing is a one-button process
Cons:
- We'll need the owner of this Github organization to do the linking to Overleaf, or give someone permission to do it.
- The actual LaTeX template will be in a subdirectory, which will be inconvenient for authors.
(2) Create a new Overleaf project (not template) that is set up to sync with this repository.
Pros: Syncing is a one-button process
Can this be done via cron job, daily, using Overleaf's git offering? Maybe wrapped in a condition that the commit hash is out of sync? Then it would need to be hosted and documented and owned, but at least it could push itself. If that git access is available to Overleaf template instances, I'd support (2).
There's another underlying issue caused by ARR decoupling template versioning from events. Previously, specific versions of the ACL template were attached to individual calls, and that template would be valid for that call. Now that ARR decouples authoring and submission from publication, there's no definition of which template versions are valid at a given time.
For a stretched but not impossible example, one might start authoring a paper in 2021, submit it in 2022, revise it, but then the grad student leaves, and so it's eventually resubmitted in 2023, and perhaps published in 2024. This means that quite old template could potentially crop up in submissions, and also that the set of articles published in any given proceedings are likely to use a mixture of different ACL template versions.
This only presents an issue if significant changes are made to the ACL template (for some definition of significant). If we want to lock ourselves into pretty much the same format for the forseeable future, there's of course no impact. On the downside, we've regularly seen cool new additions to our templates (like line numbering for review) and I think it's beneficial for chairs + community to continue to be able to do this sort of thing.
Other options could be:
- to give a sliding time window for templates, e.g. "EMNLP 2024 uses templates versions 8a7e6c1f3d49816+" or "EMNLP 2024 uses templates from March 2023 onwards"
- to stipulate a fixed template release schedule, e.g. annually on 1 Jan, and declare that the current (or current + one previous) templates are eligible
- to specify a "minimum constraints list" that all ACL templates will always adhere to, and let people use whatever fits that, and hope that reviewers and ACs don't get spooked about minor template changes. (this tactic probably has some chance of occasional false-positive desk rejects, so ACs need to be on-board)
Can this be done via cron job, daily, using Overleaf's git offering?
I don't think that's necessary; I believe an Overleaf project can be set up to use the official git repository as its underlying repository, so it would all be automatic.
The fact that the LaTeX files would be in a subdirectory seems to me an annoying problem, though, enough to make me favor (1).
Can this be done via cron job, daily, using Overleaf's git offering?
I don't think that's necessary; I believe an Overleaf project can be set up to use the official git repository as its underlying repository, so it would all be automatic.
The fact that the LaTeX files would be in a subdirectory seems to me an annoying problem, though, enough to make me favor (1).
Yeah, I agree, this would be annoying and unintuitive. There are already enough clicks between a conference homepage and the templates.
The ability to script unwrapping of this is trivial in (2). Would that tempt you?
The other question you brought up about ARR is a good one but should be made by the ARR editors. As far as maintaining the style files is concerned, I suggest we use some kind of semantic versioning (major version = can affect accept/reject decisions; minor version = improvements that don't affect accept/reject) and ARR, or any meetings not using ARR, can decide to require a minimum version number.
Maybe better than a cron job would be a GitHub action that, whenever there is a push on this repository, pushes the latex/ subdirectory into the Overleaf repository. I don't know how to do that, but maybe you or @mjpost can do it (especially since @mjpost owns the current Overleaf project).
From an ARR perspective, we point authors to the current official version; venues (conferences, workshops) would be the ones to potentially see papers using older templates. (Wouldn't it be nice if we could just have authors upload the LaTex like arXiv does? long-term future work). I think for now ARR just continues to point authors at the official repository.
Reviving this discussion - the repository and the Overleaf version are not in sync yet. Skimming the discussion above, it sounds like that is something only @mjpost can fix?
I just shared with a number of you an Overleaf project that I think has been used for some conferences. I think this has been used at least once, but I don't know for what conference. It's hard to know who's using what.
It shouldn't be too hard to set this up to automatically update; the harder item is to adopt and enforce a policy where people across conferences stick to using it.
Also, I just checked, and this might be easier than we had hoped—Overleaf has an explicit option to sync with a named Github repo. It looks like I don't have the right permissions to acl-org, though.
@jkkummerfeld do you what is the current correct version? Is it this repo, or the current template?
ARR simply points to this repository. I just checked for ACL 2023, and it had a zip file. Comparing the contents of that zip file with this repository and overleaf I see:
- acl_natbib.bst - same everywhere
- acl.sty - the ACL 2023 version is closer to the overleaf version. There is one extra line
\newcommand{\citeposs}[1]{\citeauthor{#1}'s (\citeyear{#1})}on line 210 - acl_latex.tex - The ACL 2023 version has a range of edits, including adding content about the Limitations section and Ethics Statement
Maybe the best thing is to update this repository and overleaf to match ACL 2023? (without the year specific bits) I'm happy to prepare the files and make a PR here if that's the right next step.
Reviewing this thread I see David made the exact point about Github-backed Overleaf.
I don't know about updating the repo with your suggested edits (I suppose you have jurisdiction here?) It seems reasonable. So a PR would be great.
Then we should definitely connect this repo to the overleaf. This might be a job for @desilinguist.
Re: jurisdiction... it's unclear to me who has definitive say here, since this is intended to be for general use within ACL. These edits don't seem substantive to me (just bringing in minor edits from ACL 2023 and updating the files to be consistent with standard practise re: limitations and ethics). Given that, I would assume anyone with PR-merging privileges in this repository can merge it.
Following up on this. @danielgildea and @davidweichiang, based on our discussion in the PR, this repository is correct and the overleaf is out of date.
I have updated the overleaf content to match this repository (solution (1) above). That means all is well for the immediate next cycles of ARR (ie, for EACL, NAACL, and ACL). There is still the question of a longer term solution to keeping these in sync.
Since the github README points to the overleaf project, they should really be in sync. Can you please update the overleaf project manually for now?
Someone who's a member of @acl-org-github could easily link this directly from Overleaf. I don't seem to have the right permissions.
I don't understand exactly what you're trying to do... the pasted graphic says "create a github repository", but we don't want to do that, we want to sync with this existing github repository, right? What does acl-org-github own exactly? Do you have any idea who they are?
In any case, I think we should remove the link to overleaf from the README in github if we can't update the overleaf project.