Consider reducing compute cost for rjournal.github.io (even if these CI actions don't cost us anything directly). Hosting a manually triggered deployment preview with r-project.org would be more sustainable as the size of the journal grows. We are already hitting some limits with the current number of articles in the journal.
If we switch to deploying previews less often on r-project.org web servers, we should have a redirect of https://rjournal.github.io/ to it since it seems to be used by more than just the RJ team.
I imagine most viewers of the github pages website are unaware of the difference between it and the official website. So I also suggest adding a banner that indicates that it isn't the official / released journal website, and hint visitors toward the official journal website at https://journal.r-project.org/.
Consider reducing compute cost for rjournal.github.io (even if these CI actions don't cost us anything directly). Hosting a manually triggered deployment preview with
r-project.orgwould be more sustainable as the size of the journal grows. We are already hitting some limits with the current number of articles in the journal.If we switch to deploying previews less often on
r-project.orgweb servers, we should have a redirect of https://rjournal.github.io/ to it since it seems to be used by more than just the RJ team.I imagine most viewers of the github pages website are unaware of the difference between it and the official website. So I also suggest adding a banner that indicates that it isn't the official / released journal website, and hint visitors toward the official journal website at https://journal.r-project.org/.