This is the repository for submitting to and managing the Proceedings for the Annual Scientific Computing with Python Conference.
This repository is a home for authors, reviewers and editors to collaboratively create the proceedings for the conference.
You can find more information about the proceedings' organising principles below.
All communication between authors and reviewers should be civil and respectful. There are no exceptions to this rule. Please see the SciPy Code of Conduct for more info.
You can find the schedule for 2023 below.
Please use @-mentions in issues and pull requests(PRs) to contact the proceedings Co-Chairs.
If you are an Author, please see Instructions for Authors.
If you are a Reviewer, please see Instructions for Reviewers.
If you are an Editor, please see Instructions for Editors.
If you are a Publisher, please see Instructions for Publishers.
If you are Submitting Slides, please see Instructions for Slides.
Overall, the SciPy proceedings are organised to be a fully open proceedings.
We aim to combine the best aspects of open source development, open peer review, and open access publication.
The technologies used for running the conference are themselves developed in the open and built on open source tools.
Open Development:
The systems for running the conference are built on top of open source tools:
The entire submission and review procedure occurs through public PRs attached to identifiable individuals.
Authors and reviewers are encouraged to work collaboratively to improve submissions throughout the review process, much like open source code-review.
Reviews are collaborative, aiming to improve the publication quality. This is possible because the content was already vetted by the program committee.
Conversations occur attached to people's real GitHub usernames and are open to the public.
The papers are published as true Open Access (OA) articles with Creative Commons Attribution (CC By) license.
There are no article processing charges barring authors from submitting papers.
Papers are openly available at http://conference.scipy.org/proceedings/, with no pay walls barring consumption or author processing charges.
From 2010 onward, papers have DOIs (making them easily citable) and are also openly available from those DOIs.
The community is involved in the entire process for creating the proceedings, which ensures relevance to the community that created them.
Papers are submitted by authors who will be presenting talks and posters at the annual SciPy conference. Because we know the content is relevant to the SciPy community, review can focus on improving papers, not vetting them.
Reviewers are invited by the editors, but community members may volunteer to review papers that interest them. The only barrier to participation is having a GitHub account.
The most effective way to contact the Proceedings Co-Chairs for issues related to this GitHub repository is to use GitHub's issues and "@"-mentioning the Co-Chairs.
In 2023, the Proceedings Co-Chairs are
In addition to the following list, we break up the deadlines in the respective documents for authors and reviewers.
Please submit your papers by 23:59 PST of the 1st Draft for Submission Deadline.
Submit your papers as a reStructuredText (rst) or LaTeX file via PR against this repository. Supporting LaTeX submissions is very new this year, so please consider it to be in beta, and please only use this option if you are already familiar with writing papers in LaTeX.
During the Open Review Period authors should work with their reviewers to refine and improve their submission.
Proceedings Co-Chairs have final say in determining whether a paper is to be accepted to the proceedings.
Authors should respond to all the reviewers' comments.
Authors should default to modifying their papers in response to reviewers' comments.
Authors may not agree with the reviewers comments or may not wish to implement the suggested changes. In those cases, the authors and reviewers should attempt to discuss this in the PR's comment sections. It is important to remember in these cases that we expect all communication between authors and reviewers to be civil and respectful.
In the event that authors and reviewers are deadlocked, they should alert the Proceedings Co-Chairs to this situation. As always, the Proceedings Co-Chairs have final say in whether to accept or reject a paper.
papers/00_bibderwalt
and papers/00_vanderwalt
.
00_bibderwalt
shows how to use a bib file for citations.mybib.bib
.Below we outline the steps to submit a paper.
Before you begin, you should have a GitHub account. If we refer to <username>
in code examples, you should replace that with your GitHub username.
More generally, angle brackets with a value inside are meant to be replaced with the value that applies to you.
For example, if your GitHub username was mpacer
, you would transform
git clone https://github.com/<username>/scipy_proceedings
into:
git clone https://github.com/mpacer/scipy_proceedings
scipy_proceedings
repo.scipy_proceedings
repo.2023
branch.
dev
(see below for more details).2023
branch after you start your paper.
2023
branch.git clone https://github.com/<username>/scipy_proceedings
cd scipy_proceedings/
scipy-conference
repository as your upstream
remote
git remote add upstream https://github.com/scipy-conference/scipy_proceedings
If you run git remote -v
you should see something like the following:
origin https://github.com/<username>/scipy_proceedings.git (fetch)
origin https://github.com/<username>/scipy_proceedings.git (push)
upstream https://github.com/scipy-conference/scipy_proceedings.git (fetch)
upstream https://github.com/scipy-conference/scipy_proceedings.git (push)
scipy_proceedings
repo
git fetch upstream
2023
branch
git checkout -b 2023 --track upstream/2023
.
If you are submitting only one paper, you can use the 2023
branch directly.
Otherwise, you will need to create a new branch based on 2023
and set its
upstream to origin.
git checkout 2023
git checkout -b <your_branch_name>
git push --set-upstream origin <your_branch_name>
pyenv
or conda
).pip install -U -r requirements.txt
).papers/<your_directory_name>
.
<firstname_surname>
.<your_directory_name>
.paper/<your_directory_name>
If you want to change the way the build system works, we use a separate submission procedure (see below).
./make_paper.sh papers/firstname_surname
to make a PDF of your paperoutput/<your_directory_name>/paper.pdf
.2023
branch.If you want to change the way the build system works, we use a separate submission procedure.
dev
.dev
branch, it will be reviewed separately.When you push to your repositories branch it automatically updates the PR. This triggers a new build on the provided build server.
We encourage reviewers to review the PDFs built on our build server.
You should regularly check to see if the paper(s) that you build locally match the paper(s) that you see on the server.
If it is not the same, please immediately contact us with a GitHub issue describing the discrepancy. Please include screenshots and an explanation of the differences. For best results, please @-mention the Proceedings Co-Chairs.
You will be reviewing authors' pull requests. While authors should have a proper draft of their paper ready for you by 1st Draft Submission deadline.
We ask that you read this set of suggested review criteria before beginning any reviews.
All communication between authors and reviewers should be civil and respectful at all times.
The goal of our review process is to improve the paper that the authors are working on. Our aim is to have you and the author collaborate on making their better by using an iterative process.
While our basic approach is to have you and the author iterate, we ask you to complete an initial review and start that conversation by the Initial Complete Review Deadline.
We ask that by the Final Recommendation Deadline you have a recommendation to either accept or reject the paper at that point and time.
Note: You many recommend changes after the Final Recommendation Deadline. If there are any major changes after the Final Recommendation Deadline you should immediately contact the Proceedings Committee Co-Chairs. As a heuristic, if you think the paper should not be in the proceedings unless the authors make the change in question, then that change should be requested and made before the Final Recommendation Deadline.
A small subcommittee of the SciPy 2017 organizing committee has created this set of suggested review criteria to help guide authors and reviewers alike. Suggestions and amendments to these review criteria are enthusiastically welcomed via discussion or pull request.
pip install -r requirements.txt
texlive-publishers
, or download from
CTAN) LaTeX
classtexlive-bibtex-extra
, or download from
CTAN) urlbst BibTeX stylesudo 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.
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`
There will be a server online building open pull requests at http://procbuild.scipy.org.
Authors: you should check to ensure that your local builds match the papers built on this site. Please create an issue if they do not match.
Reviewers: You should be able to pull a built PDF for review from there.
To information about how to manage the whole proceedings, please see
publisher/README.md
and publisher/Makefile
.
As reviewers review papers, editors should apply labels to the PR to flag the current state of the review process.
Editors should come to a final 'ready', 'unready' decision before the Final Editorial Decisions for Proceedings Contents deadline.
scipy_proceedings
repo.scipy_proceedings
repo.2023
branch.presentations
folder, there are directories for:
info.json
with the following fields needed for uploading to Zenodo (using an empty string for author orcid or
affiliation if these cannot be provided):
{
"title": "The title of your presentation",
"authors": [
{
"name": "The first author or presenter",
"affiliation": "first author's affiliation",
"orcid": "0000-0000-0000-0000"
},
{
"name": "The second author or presenter",
"affiliation": "second author's affiliation",
"orcid": "0000-0000-0000-0001"
}
],
"description": "1-4 sentences explaining what your presentation is about"
}
You can see examples of submissions in the example
folder in each presentation directory.