Update README

scipy-conference · Apr 9, 2024 · 12837eb · 12837eb
1 parent a2d16df
commit 12837eb
Show file tree

Hide file tree

Showing 6 changed files with 239 additions and 248 deletions.
diff --git a/README.md b/README.md
diff --git a/make_paper.sh b/make_paper.sh
diff --git a/publisher/README.md b/publisher/README.md
@@ -1,5 +1,7 @@
 # For editors publishing the proceedings.
 
+**Note**: This is changing in 2024 and aspects of this README are out of date.
+
 ## Structure of the proceedings
 
 This section will give you an introduction to the various documents and resources that you will need to create in the course of managing the proceedings.
@@ -44,11 +46,11 @@ The resulting html files will include:
 - `index.html`
 - a page for each article, named ``<article_author>.html`
 - a `bib/`` directory, containing:
-    - a bibfile for each article, named `<article_author>.bib`
-    - a bibfile for the complete proceedings, named `proc-scipy-<year of proceedings>.bib`
+  - a bibfile for each article, named `<article_author>.bib`
+  - a bibfile for the complete proceedings, named `proc-scipy-<year of proceedings>.bib`
 - a `pdf/` directory, containing:
-    - a pdf for each article, named `<article_author>.pdf`
-    - a pdf for the complete proceedings, named `proceedings.pdf`
+  - a pdf for each article, named `<article_author>.pdf`
+  - a pdf for the complete proceedings, named `proceedings.pdf`
 
 ## Building the proceedings: Makefile
 
@@ -86,6 +88,28 @@ NB: You will tend to use `html-zip` if you need to iterate on the portable copy
 of the website without needing to rebuild the entire proceedings. This is most
 useful after authors' PRs are no longer being updated.
 
+## Requirements
+
+These requirements are for installing LaTeX, which should not be necessary for MyST based submissions.
+
+### Debian-like distributions:
+
+```
+sudo apt-get install python-docutils texlive-latex-base texlive-publishers \
+                     texlive-latex-extra texlive-fonts-recommended \
+                     texlive-bibtex-extra
+```
+
+Note you will still need to install `docutils` with `pip` even on a Debian system.
+
+### Fedora
+
+On Fedora, the package names are slightly different:
+
+```
+su -c `dnf install python-docutils texlive-collection-basic texlive-collection-fontsrecommended texlive-collection-latex texlive-collection-latexrecommended texlive-collection-latexextra texlive-collection-publishers texlive-collection-bibtexextra`
+```
+
 ## Build styles
 
 There are three different modes for publishing the proceedings, you will need to
@@ -106,18 +130,18 @@ can be served on the official SciPy organisation website.
   be used to publish the final version of the proceedings. Using "ready" is
   responsible for triggering the creation of DOIs and XML submission files.
 
-  ## DOI metadata
+## DOI metadata
 
 As of 2015, each SciPy conference proceedings and the individual papers in
 one proceedings are assigned DOIs. As of 2018, the conference itself has a
 DOI, such that the linking structure now looks the following:
 
 - ISSN + Series DOI (10.25080/issn.2575-9752)
-    - Conference DOI for SciPy 2018
-    - Conference DOI for SciPy 2017
-        - Paper DOI for Poore 2017
-        - Paper DOI for Niederhut 2017
-        - etc.
+  - Conference DOI for SciPy 2018
+  - Conference DOI for SciPy 2017
+    - Paper DOI for Poore 2017
+    - Paper DOI for Niederhut 2017
+    - etc.
 
 The organization that administers ISSN requests that [the series-level DOI
 be constructed following these guidelines]
@@ -134,6 +158,7 @@ This ends up looking like `10.25080/shinma-7f4c6e7-002`. When displaying DOIs,
 crossref.org asks that we use this format -
 [https://doi.org/10.25080/shinma-7f4c6e7-002]
 (https://doi.org/10.25080/shinma-7f4c6e7-002)
+
 - which resolves the proceedings page where the paper is hosted.
 
 Submitting DOIs and associated metadata about each paper to crossref.org

diff --git a/publisher/getting_ready_for_new_year.md b/publisher/getting_ready_for_new_year.md
@@ -1,77 +1,77 @@
 # Getting ready for the new year's proceedings
 
-We're going to assume that you are working in year *x* to set up the proceedings
-system for SciPy *x*. 
+We're going to assume that you are working in year _x_ to set up the proceedings
+system for SciPy _x_.
 
 This workflow requires a few steps. We will list those steps here, but if you
-don't know what some of the words mean, we highly recommend that you read 
+don't know what some of the words mean, we highly recommend that you read
 [the problem section](#What-problem-are-we-solving).
 
 # Workflow
 
 All development work should have been occurring on the `dev` branch of the repo.
 
-1. Merge `dev` into `master`
-1. Create new branch for year `x` based off of the new `master`
+1. Merge `dev` into `main`
+1. Create new branch for year `x` based off of the new `main`
 1. Update the default branch
    - ![Update default branch](./images/update_default_branch.png)
 1. (potential step) If you have a new server location, you need to update the webhook
 1. Update the docs to reflect all of the above changes
    - that includes:
-       - `scipy_proceedings/README.md`
-       - `scipy_proceedings/publisher/README.md`
-       - `scipy_proceedings/publisher/getting_ready_for_new_year.md`
+     - `scipy_proceedings/README.md`
+     - `scipy_proceedings/publisher/README.md`
+     - `scipy_proceedings/publisher/getting_ready_for_new_year.md`
 
-## What problem are we solving? 
+## What problem are we solving?
 
 For the purposes of this explanation, we're going to describe the workflow in
-terms of what needs to be done in the repo in the year `x = 2018`. 
+terms of what needs to be done in the repo in the year `x = 2018`.
 
 We organise the repo around git branches, specifically we're going to be thinking about 4 branches:
 
-- `master`: the master branch, reflecting the canonical source of the proceedings system
+- `main`: the main branch, reflecting the canonical source of the proceedings system
 - `dev`: the development branch, reflecting the up-to-date source of the proceedings system
 - `2017`: the previous year's proceedings' branch
 - `2018`: this year's proceedings' branch (this branch does not yet exist)
 
 Most of the decisions we need to make revolve around what we want to do with
 each of these branches.
 
-### What goes into `master`?
+### What goes into `main`?
 
-In `2017` we have a lot of things that differ from `master`. On the one hand,
+In `2017` we have a lot of things that differ from `main`. On the one hand,
 there are all the great changes that were made by the previous year's
 proceedings committee. We're going to definitely want to have those in our
-`master` branch. However, `2017` also has all of the papers that were submitted
+`main` branch. However, `2017` also has all of the papers that were submitted
 by the authors of the 2017 proceedings.
 
-**We never want to have any real papers in master, ever**. `master` is supposed
+**We never want to have any real papers in main, ever**. `main` is supposed
 to only ever reflect the build system itself. That means the only papers that
-should ever be in `master` should be the demo papers.
+should ever be in `main` should be the demo papers.
 
-We want to keep `master` and its history as small as possible. It is intended to
+We want to keep `main` and its history as small as possible. It is intended to
 transcend any particular year, and should not be tied to any of the history of
-the proceedings system. Additionally, this keeps `master` as small as possible.
+the proceedings system. Additionally, this keeps `main` as small as possible.
 
-So, we only want to put the changes to the build system in master. But people
+So, we only want to put the changes to the build system in main. But people
 have to submit their proceedings to `2017` in 2017, and `2018` in 2018. How can
-we get the improvements to the system without getting the papers? 
+we get the improvements to the system without getting the papers?
 
 ### `dev` is where build changes go
 
-The solution to the previous section problems is the `dev` branch. 
+The solution to the previous section problems is the `dev` branch.
 
 `dev` specifically exists to house the improvements to the system, without any
-of the papers. 
+of the papers.
 
 That means during the 2018 proceedings any work that is being done to improve
 the system should be in PRs made against `dev`, not `2018`.
 
-### Base the new year's branch (e.g., `2018`) off of `master`
+### Base the new year's branch (e.g., `2018`) off of `main`
 
-After merging `dev` into `master`, can branch `2018` off of `master`.
+After merging `dev` into `main`, can branch `2018` off of `main`.
 
-### Merge `dev` into `2018` on an on-going basis. 
+### Merge `dev` into `2018` on an on-going basis.
 
 But as you are developing the system, you will be making changes to address
 specific problems that come up for authors. If we aren't putting any changes in
@@ -92,4 +92,3 @@ TODO: Figure out workflow to move previous year's branch into its own repo.
 
 Once we write up the workflow, this should be added to the todo list under
 [](#Workflow).
-
diff --git a/requirements.txt → publisher/requirements.txt b/requirements.txt → publisher/requirements.txt
diff --git a/pull_request_template.md b/pull_request_template.md
@@ -1,11 +1,9 @@
 If you are creating this PR in order to submit a draft of your paper,
-see http://procbuild.scipy.org/ for logs generated by the build
-process.
+please tag your PR with `paper` and a GitHub Action will be run to check and build your paper.
 
-See the [project readme](https://github.com/scipy-conference/scipy_proceedings#build-your-paper)
+See the [project readme](https://github.com/scipy-conference/scipy_proceedings#preview-your-paper)
 for more information.
 
+_Editor_: <!--editor--> <!--end-editor-->
 
-*Editor*: <!--editor--> <!--end-editor-->
-
-*Reviewers*: <!--reviewers-list--> <!--end-reviewers-list-->
+_Reviewers_: <!--reviewers-list--> <!--end-reviewers-list-->