Issue build

Article workflow

The life of the article in the workflow during the editorial stage happen in the articles repository and is documented in the Editors' Guide (sources live here). In essence, the review process happens in Submissions and then upon the editorial decision it is moved to either Accepted or Rejected.

Once the article is accepted it is waiting for the inclusion in the new issue. Each new issue is built by moving the corresponding accepted articles into the Proofs directory which has the sources for all issues (including past ones, each in YYYY-I directory). The article is proofed there (copy-edited and final updates by authors) until it's ready to be published.

The publishing step consists of creating a corresponding entry in the rjournal.github.io repository (informally the web repository) via publish_article(id, vol, issue). Important: the function assumes that both articles and rjournal.github.io repositories are checked out in the same top-level directory and rjournal.github.io should be on its master branch. It renders the article and the rendering is copied into the web repository. The master branch is used as the development area holding the necessary distill sources while the issue is assembled. It has an automated action which generates the actual web pages (via rmarkdown::render_site()) into the render-test branch which is also visible at the https://rjournal.github.io/ URL.

Once the issue is ready to be published, the master branch is merged into the published branch. The action there then generates the deploy branch which is served by the official website.

   master    --render-->  render-test    (https://rjournal.github.io)   
     | merge
     V
  published  --render-->  deploy         (https://journal.R-project.org)

Please note that both deploy and render-test branches are auto-generated, so changes should only be made in the master branch (and then merged to published). In principle, manual overrides can be done using the legacy-content branch which is always copied into the web area after the site is generated, but it is discouraged if fixes can be done in the master branch instead.