scipy-conference/scipy_proceedings

Tools used to generate the SciPy conference proceedings

SciPy Proceedings

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 NumFOCUS Code of Conduct for more info. Attendees at SciPy 2024 are subject to the NumFOCUS Code of Conduct.

You can find the schedule for 2024 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.

Organising Principles: Openness

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.

Built by and for Open Source Communities on Open Source Tech

The technologies used for running the conference are themselves developed in the open and built on open source tools.

Open Development:

• with many people contributing code over more than a decade
  • many contributors start as authors submitting to the proceedings
  • provides a natural pathway for new members to join the proceedings committee
• technologies are managed via public, open source GitHub repositories

The systems for running the conference are built on top of open source tools, including:

• MyST Markdown (mystmd.org)
• Typst - for fast PDF generation (e.g. SciPy template)

Open Peer Review meets Open Source Code Review

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.

  • This allows for a transparent open review process.
  • This holds authors and reviewers accountable and encourages civil communication practices.

Open Access for an Open Community

The papers are published as true Open Access (OA) articles with Creative Commons Attribution (CC-BY-4.0) license.

• There are no article processing charges barring authors from submitting papers.

  • Reviewers and co-chairs volunteer their time.
  • Services with free tiers (like GitHub) allow distributing the underlying technologies with minimal cost.

• Papers are openly available at http://proceedings.scipy.org, 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.

• From 2023 onwards, full HTML is the preferred format in addition to the PDF being available.

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.

Contacting the Proceedings Co-Chairs

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 2024, the Proceedings Co-Chairs are:

• Meghann Agarwal (@mepa)
• Amey Ambade (@ameyxd)
• Chris Calloway (@cbcunc)
• Rowan Cockett (@rowanc1)
• Sanhita Joshi (@sanhitamj)
• Charles Lindsey (@cdlindsey)
• Hongsup Shin (@hongsupshin)

Timeline for 2024

In addition to the following list, we break up the deadlines in the respective documents for authors and reviewers.

• Apr 9: Reviewer invitations sent
• Apr 23: Deadline to respond to offer to be a reviewer
• Apr 26: Authors invited to submit full papers
• May 3: Webinar offered to authors
• Jun 7: Deadline to submit first draft by authors
• Jun 8: Assignment of reviewers to papers
• Jun 8: Open Review Period begins
  • Reviewers comment on papers to authors during this period.
  • Authors also respond to review comments with improvements to papers during this period.
• Jul 3: Initial complete review
  • Reviewers continue to comment on paper improvements during this period.
  • Authors also respond to review comments with further improvements to papers during this period.
• Aug 19: Final review deadline
  • Authors continue to make revisions in response to final review comments during this period.
• Sept 2: Final author revision deadline
• Sept 2: Open Review Period ends
  • Authors put down their pens.
  • Reviewers make an up or down decision on publication readiness of papers during this period.
• Sept 9: Final reviewer decision deadline
• Sept 23: Proceedings final sign-off by editors
  • The publication process begins after final sign-off.

Instructions for Authors

Please submit your papers by 23:59 PST of the Deadline to submit first draft.

Submit your papers as a MyST Markdown (mystmd.org) or LaTeX file via PR against this repository. Please only use LaTeX if you are already familiar with writing papers in LaTeX. The build process are using the mystmd CLI in 2024, which allows us to support a web-first reading experience. In future years this will allow us to accept notebooks and computational environments, however, this is not available in 2024.

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.

Getting Help

An excellent webinar entitled "SciPy Proceedings 2024: Quickstart and authoring tutorial" is available on YouTube.

If you have a challenge with any technical aspect of authoring your paper in MyST or LaTeX, please do not hesitate to reach out via your GitHub pull request or issue on this repository. A member of the Proceedings Co-chairs will help you directly or identify a work-around.

Author Deadlines

• Apr 26: Authors invited to submit full papers
• May 3: Webinar offered to authors
• Jun 7: Deadline to submit first draft by authors
  • Reviewers comment on papers to authors during this period.
  • Authors also respond to review comments with improvements to papers during this period.
• Sept 2: Final author revision deadline
  • Authors put down their pens.

General Information and Guidelines for Authors

• Papers are formatted using MyST (mystmd.org) or LaTeX (which also uses MyST, please see notes on LaTeX below)
• The paper is written and reviewed using the interactive HTML view (i.e. myst start), the PDF is built upon acceptance only
• Example papers are provided in papers/00_myst_template and papers/00_tex_template
  • These papers provide examples of how to:
    • Label figures, equations and tables
    • Use math markup
    • Include code snippets
    • Use a BibTeX files and/or DOIs for citations
• When creating your pull-request, add a pull-request label of paper to trigger the build process. If you do not add this, a proceedings chair member will add it for you.
• Authors may include a project or consortium (e.g. The Jupyter Project)
• There must be at least one corresponding author, and this must be a specific person with a valid email address
• Authors of papers from previous SciPys may change their name on their published work by contacting the Proceedings Co-chairs
• All citations that have DOIs should include those DOIs in the paper's references section, see mybib.bib.
• All figures and tables should have captions.
• Figures and tables should be positioned close to their explanatory text.
• All abbreviations should be identified in your myst.yml (docs)
• License conditions on images and figures must be respected (Creative Commons, etc.)
• Images and figures should be reasonably sized and formatted for viewing online; typically less than 1 MB
• Do not modify any files outside of your paper directory
• When using the LaTeX option, please consider:
  • SciPy is supporting HTML. LaTeX is not involved in reading or rendering (as of 2024 we use Typst for building PDFs)
  • Custom LaTeX macros are not supported and some packages may not be supported
• The compiled version of the paper should be at most 6000 words

including figures but not including references; this is about 8 pages for the published PDF that will be created upon acceptance.

Author Workflow

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 you typically clone using the web URL, and your GitHub username was mpacer, you would transform

git clone <scheme>github.com/<username>/scipy_proceedings.git

into:

git clone https://github.com/mpacer/scipy_proceedings

Author workflow steps

Note

There is a webinar on YouTube that goes through the author submission process for 2024 submissions using MyST Markdown.

1. Get a local copy of the scipy_proceedings repo.
2. Update your local copy of the scipy_proceedings repo.
3. Create a new branch for your paper based off the latest 2024 branch.
   • If you submit multiple papers, you will need a new branch for each.
4. Install MyST Markdown and Node and copy a template.
5. Write your paper, commit changes, and build your paper
6. Create a PR or push changes to your PR's branch and check your paper.
   • If you want to alter other parts of the scipy_proceedings repo, do not include it in your submission's PR, create a separate PR against dev (see below for more details).
   • Creating build system PRs is deprecated in 2024. Curvenote is the build system now.
7. Repeat steps 5 and 6, while also responding to reviewer feedback.

Getting a local copy of the scipy_proceedings repo

• If you do not have a GitHub account, create one.
• Fork the scipy_proceedings repository on GitHub.
• Clone the repo locally
  • replace <scheme> with git@ or https://, for example
  • replace <username> with your GitHub username
  • git clone <scheme>github.com/<username>/scipy_proceedings.git
  • cd scipy_proceedings/
• Add the scipy-conference repository as your upstream remote
  • git remote add upstream <scheme>github.com/scipy-conference/scipy_proceedings

If you run git remote -v you should see something like the following:

origin	<scheme>github.com/<username>/scipy_proceedings.git (fetch)
origin	<scheme>github.com/<username>/scipy_proceedings.git (push)
upstream	<scheme>github.com/scipy-conference/scipy_proceedings.git (fetch)
upstream	<scheme>github.com/scipy-conference/scipy_proceedings.git (push)

Getting the latest branch

• Fetch the latest version of the scipy_proceedings repo
  • git fetch upstream
• Check out the upstream 2024 branch
  • git checkout -b 2024 --track upstream/2024

Creating a new branch

If you are submitting only one paper, you can use the 2024 branch directly.

Otherwise, you will need to create a new branch based on 2024 and set its upstream to origin.

git checkout 2024
git checkout -b <your_branch_name>
git push --set-upstream origin <your_branch_name>

Setting up your environment

• Optional: Create a new environment (using your choice of environment manager, e.g., pyenv or conda).
• Install MyST Markdown from mystmd.org
  • pip install mystmd
  • Install nodejs (see options)
• Create a new directory papers/<your_directory_name>
  • if you are submitting one paper, we recommend you use <firstname_surname>
  • if you are submitting more than one paper, you will need to use a different directory name for each paper
• Copy an example paper into your directory: either papers/00_myst_template or papers/00_tex_template
  • Update the id in the myst.yml to by scipy-2024-<your_directory_name>

Write your paper

• To have a live preview of your changes:
  • Change directories cd papers/<your_directory_name>
  • Run myst start and open the web-server provided
• Refer to the syntax in the template papers or online at mystmd.org
• Update the author information and affiliations in myst.yml
• As you make changes to your paper, commit those changes in discrete chunks
• If you come across any challenges, ask the Proceedings Co-chairs for help via a GitHub issue or comment on your PR

Note: The templates are setup for a single MyST/LaTeX file in the top level of <your_directory_name>. If you have more than one file run myst init --write-toc (docs), ensuring that the root is the main file of your manuscript.

Commit your changes

• Commit any changes inside the papers/<your_directory_name>
• When you push your commits to your PR's branch, the paper will be auto-built in GitHub actions
• Do not commit any changes to files outside of your paper directory

If you want to alter other parts of the scipy_proceedings repo, we use a separate submission procedure (see below).

Preview your paper

Your paper will be edited and reviewed in HTML, the PDF will only be built on acceptance.

To preview your paper:

• Ensure mystmd is installed (guide)
• In papers/<your_directory_name> run myst start
• Open the web-server from your console
• Check that this output matches what is built on your PR

Create a paper PR

Once you are ready to submit your paper, make a pull request on GitHub. Please ensure that you file against the correct branch.

• Create a pull request against the 2024 branch
• Do not modify any files outside of your paper directory. Create a separate PR for any changes to the build system.
• Ensure that your PR title begins with Paper:. Note: for the first commit in your PR, an editor will add the paper label, which will start the GitHub actions.

Creating build system PRs

Creating build system PRs is deprecated in 2024. Curvenote is the build system now.

If you want to change documentation, etc., we use a separate submission procedure.

• Create a new branch against dev
• Make your changes
• Do not commit any changes from your paper PR to this new branch
• Make a separate PR against the dev branch, it will be reviewed separately

Push to your PR

When you push to your repositories branch it automatically run GitHub actions on the PR. Note that this will require authorization for your first commit only. The build process takes about a minute, and then posts or updates a comment on the PR with a link to the build result on Curvenote. The build page has a link to your preview.

Check your paper's build

The review process will be completed on the HTML, and you can check to see if the paper(s) that you preview locally match the paper(s) that you see online. These will be available in a GitHub comment or through the logs in the GitHub action.

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.

A note on notebooks for 2024

We are interested in working towards full support for publishing computational notebooks as part of the proceedings, and are trialing this part of the submission process for interested authors - please get in touch with the Proceedings Co-Chairs with your interest.

Instructions for Reviewers

You will be reviewing authors' pull requests. While authors should have a proper draft of their paper ready for you by the Deadline to submit first draft.

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 Reviewer Decision 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 Reviewer Decision deadline. If there are any major changes after the Final Reviewer Decision 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 Reviewer Decision deadline.

Reviewer Deadlines

• Apr 9: Reviewer invitations sent
• Apr 23: Deadline to respond to offer to be a reviewer
• Jun 8: Assignment of reviewers to papers
  • Reviewers comment on papers to authors during this period.
  • Authors also respond to review comments with improvements to papers during this period.
• Jul 3: Initial complete review
  • Reviewers continue to comment on paper improvements during this period.
  • Authors also respond to review comments with further improvements to papers during this period.
• Aug 19: Final review deadline
  • Authors continue to make revisions in response to final review comments during this period.
• Sept 2: Final author revision deadline
  • Authors put down their pens.
  • Reviewers make an up or down decision on publication readiness of papers during this period.
• Sept 9: Final reviewer decision deadline

Reviewer Workflow

• Read this set of suggested review criteria
• Click on the Pull Requests Tab and find the papers assigned to you
• A comment at the top of the PR will have a link to the paper to review online
• After reading the paper online, you can start the review conversation however you prefer
  • You can use in-line comments (on the paper itself) or high-level comments.
• Authors will respond to your comments, possibly via their own comments or by modifying their paper.
• This begins an iterative review process where authors and reviewers can discuss the evolving submission.
• By the Final Reviewer Decision deadline, we ask that you give two things
  1. A comprehensive review of the paper as it stands. This will act as the final review.
  2. A final recommendation to include the paper in the proceedings or not.
     • When you make the Final Recommendation, please contact the proceedings Co-Chairs in the PR in question.

Review Criteria

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.

Requirements

• MyST Markdown (mystmd) and NodeJS (>18)
• GitHub actions for the build process

Build Process

The build process is completed through GitHub actions on every commit. A comment is posted after the build process completes with a list of checks and a link to the built output on Curvenote.

Authors: you should check to ensure that your local builds match the papers built online. Please create an issue if they do not match.

Reviewers: You should be able to see the built article from the GitHub comment, and review from the preview link.

For organisers

Instructions for Publishers

To information about how to manage the whole proceedings, please see publisher/README.md and publisher/Makefile.

Publisher Deadlines

• Apr 26: Authors invited to submit full papers
  • The build process is supported by Curvenote (a SciPy sponsor) and it is maintained throughout this period.
• Sept 23: Proceedings final sign-off by editors
  • The publication process begins after final sign-off.

Instructions for Editors

As reviewers review papers, editors should apply labels to the PR to flag the current state of the review process. All paper PRs must have the paper label before the GitHub action will be triggered. Additionally, as editors and reviewers are assigned, the editors should add the reviewers GitHub handles to the PR summary comment.

Other labels that should be used are:

• needs-more-review if the paper needs further review,
• pending-comment if the paper is waiting on an authors' response, or
• unready if the paper is not ready for the proceedings.

Editors should come to a final 'ready', 'unready' decision before the Final Editorial Decisions for Proceedings Contents deadline.

Editor Deadlines

• Apr 9: Reviewer invitations sent
• Apr 23: Deadline to respond to offer to be a reviewer
• Apr 26: Authors invited to submit full papers
• Jun 8: Assignment of reviewers to papers
  • Reviewers comment on papers to authors during this period.
  • Authors also respond to review comments with improvements to papers during this period.
• Jul 3: Initial complete review
  • Reviewers continue to comment on paper improvements during this period.
  • Authors also respond to review comments with further improvements to papers during this period.
  • Editors should verify that reviews have been completed
• Sept 23: Proceedings final sign-off by editors
  • The publication process begins after final sign-off.

Instructions for Slides

Slide/Poster submission steps

1. Get a local copy of the scipy_proceedings repo.
2. Update your local copy of the scipy_proceedings repo.
3. Create a new branch for your paper based off the latest 2024 branch.
4. Inside the presentations folder, there are directories for:
   1. 3-minute lightning talk slide decks (lightning)
   2. Posters presented at the poster session (posters)
   3. 30-minute talk slide decks (slides)
   4. SciPy tools plenary slide decks (tools)
5. Choose the appropriate folder, and make a new directory inside it (it needs a unique name)
6. Copy your slide deck or poster into the directory, and add a file called 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"
}

7. Create a PR

You can see examples of submissions in the example folder in each presentation directory.

scipy_proceedings's Issues

Automated Bibliography Management

Hi guys, I am trying to use the scipy proceedings format to self-publish some scientific results (see https://github.com/TheChymera/OPR.OPR-Concepts-Guidelines/blob/master/paper/paper.rst#spi02 for the according guidelines paper I am writing). Previously I tried to do this via LaTeX ( https://github.com/TheChymera/OPR.Concepts-Guidelines-for-OPR ), and even though that approach was inferior - at least I could automatically build and compile my bibliography.

Is there any more automated way to manage the bibliography of a paper written according to the scipy proceedings format? As it is I'm forced to write every bib entry by hand, and being a very cite-happy writer that's a pain.

Paper Generation Error with :corresponding: tag

I was working on #224 and found this while reconciling changes:

:author: David L
:corresponding: David L
:email: [email protected]
:institution: RealMassive, Inc.

:author: Joe Schmo
:corresponding: Joe Schmo
:email: [email protected]
:institution: Schmo, Inc

:author: A L
:corresponding: A L
:email: [email protected]

:author: Jason V
:corresponding: Jason V
:email: [email protected]
:institution: RealMassive, Inc.

:author: D L
:corresponding: D L
:email: [email protected]

The :author: tag works, but only for the first corresponding author. Adding :corresponding: and :author: tags also cause the error, as does the 00_vanderwalt.rst file on master and 2016 branches.

Stack trace:

Traceback (most recent call last):
  File "publisher/build_paper.py", line 229, in <module>
    build_paper(paper_id)
  File "publisher/build_paper.py", line 214, in build_paper
    rst2tex(in_path, out_path)
  File "publisher/build_paper.py", line 88, in rst2tex
    settings_overrides=settings)
  File "/usr/lib/python2.7/dist-packages/docutils/core.py", line 414, in publish_string
    enable_exit_status=enable_exit_status)
  File "/usr/lib/python2.7/dist-packages/docutils/core.py", line 662, in publish_programmatically
    output = pub.publish(enable_exit_status=enable_exit_status)
  File "/usr/lib/python2.7/dist-packages/docutils/core.py", line 219, in publish
    output = self.writer.write(self.document, self.destination)
  File "/usr/lib/python2.7/dist-packages/docutils/writers/__init__.py", line 80, in write
    self.translate()
  File "/usr/lib/python2.7/dist-packages/docutils/writers/latex2e/__init__.py", line 247, in translate
    self.document.walkabout(visitor)
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 174, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 166, in walkabout
    visitor.dispatch_visit(self)
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 1882, in dispatch_visit
    return method(node)
  File "/home/dalippa/scipy_proceedings/publisher/writer/__init__.py", line 102, in visit_field_body
    self.corresponding.append(self.author_names[-1])

PythonTeX and .rst publishing

Hello, I am trying to write up some guidelines for revision-oriented publishing ( https://github.com/TheChymera/OPR.Concepts-Guidelines-for-OPR ). As it makes little sense to version figures over git - it would be awesome to have them plotted at compile time (which PythonTeX does). However, though I very much like LaTeX, I am thinking of maybe writing my papers as .rst (so that they can easily be read w/o requiring the user to compile them) - can PytonTeX be used from within .rst documents such as the ones used for the scipy proceedings?

Questions about .rst and tex formatting.

Hey everyone,

I'm new to .rst and encountered a few issues in how the .tex document is constructed given the .rst source. If anyone has any expertise in this area, can you help me out and also send your answers to my email address ([email protected])? Thanks.

1. I used numbers as my as variables to my reference my citations. The example document uses words. For example:

[1] vs [ref 1] for reference 1
[2] vs [ref 2] for reference 2

I did this because, if you look at the example document, these variable names do appear in the references section. I think this is in contrast to standard citation practices where the reference list is almost always a list of integers. In doing this, I've screwed up how the references appear in the document. My "Reference" section header does not appear for example.

1. For footnotes, the symbols do not reset on each page. For example, the first footnote on each page ought to be an asterisk; however, the .tex file is going through the full gamut of symbols. This results in some obscure superscripts. Is there a way to correct this?

Thanks.

add video links to all papers 2016

ObjArray paper link showing cesium paper on build server

@stefanv I've been trying to debug this, I closed the PR for objarray and have now reopened it, but on the build server the link for ObjArray always displays the paper for Cesium instead of Objarray. The link for cesium displays the paper for Cesium.

I've cleared the cache and run update_prs, the pr_list file has ObjArray and the right information. I've also been adding print statements throughout the build scripts and all the information looks correct (paper number, url, etc), but somehow the wrong paper shows up at the end. Any help debugging would be appreciated.

no module named docutils

Getting this error on my attempt to build a copy of 00_vanderwalt paper on Ubuntu 14.04

./make_paper.sh papers/sebastian_benthallTraceback (most recent call last):
  File "publisher/build_paper.py", line 4, in <module>
    import docutils.core as dc
ImportError: No module named 'docutils'

.. note:: doesn't work correctly

I'd like to put a "note" in my paper. This is part of standard ReST, but in the paper it causes the text to extend across both columns.

This is caused by the following block:

% admonition (specially marked topic)
\providecommand{\DUadmonition}[2][class-arg]{%
  % try \DUadmonition#1{#2}:
  \ifcsname DUadmonition#1\endcsname%
    \csname DUadmonition#1\endcsname{#2}%
  \else
    \begin{center}
      \fbox{\parbox{0.9\textwidth}{#2}}
    \end{center}
  \fi
}

The number before \textwidth should be <0.5, I guess.

only the first table gets booktabs

This can be observed in the demo doc, where table 1 gets booktabs and tables 2 and 3 do not.

This doesn't seem to be a property of the tables themselves, since rearranging them within the source document still ends up with the same behavior.

Spurious spacing in references

Based on my experimentation, it looks like any reference beginning with an author initial must have a second line. Otherwise, there is extra spacing before the author name. And the extra spacing disappears if there isn't a period after the initial, or if there is only a period by itself.

Compare extra spacing before the L. produced by

.. [HEVEA]  L. Maranget. "HEVEA." http://hevea.inria.fr/.

versus the output of

.. [HEVEA] L. Maranget. "HEVEA."
           http://hevea.inria.fr/.

See the discussion in #62 (comment).

allow building papers straight from LaTeX

An issue that got raised as a result of last year's review process is that some more traditional academics would prefer if they could submit papers in LaTeX directly rather than as ReStructuredText

make_paper.sh hangs

I haven't looked into it yet, but a fresh checkout of the scipy_proceedings followed by

./make_paper.sh papers/00_vanderwalt
*** Warning: /home_mint/bergstra/V/skdata/src/scipy_proceedings/publisher/_static/institutions.json does not exist.
Building: 00_vanderwalt
*** Warning: /home_mint/bergstra/V/skdata/src/scipy_proceedings/publisher/../output/00_vanderwalt/paper_stats.json does not exist.

just hangs there not doing anything. I haven't investigated, but if someone else fixes this before me let me know :)

Email from more than one author

Is there a way to get it to display more than one authors' emails as corresponding authors? Or should that be included in the text manually (e.g., in the conclusion; in a footnote; in acknowledgments; &c.)?

Copyright holder different than authors.

@dalippa suggested (in #135) that you sometimes want the copyright holder to be different than the authors... so... let's make that change to the template.

Wide (two-columns) Figures

Quick question: are wide figures appropriate for our publication medium?

If so, how can we convince restructured -> docutils -> latex to use a latex "figure_" (as opposed to "figure"). Would the entire latex figure_ environment and content have to be hard coded in the original rst document?

Best,
Mark

link in README to review_criteria.md broken in GitHub view

Following the link on REAME preview on this page:

https://github.com/scipy-conference/scipy_proceedings

to the review criteria is broken, leading to this url:

https://github.com/scipy-conference/scipy_proceedings/review_criteria.md

a possible alternative URL for this link (which leads to a page on which one can read the review criteria) is:

port to Python 3

Add link to published proceedings

Add links to the README pointing to all previous years' published proceedings (P.S., where are they?)

BUG: Compling papers has 2010 dates

Copyright and titling is 2010.. If I get around to it I will submit PR.. Should be done under 2014 branch right?

Built papers have SciPy 2010 headers

Looks like that is getting pulled in from

scipy_proceedings/scipy_proc.json

Line 8 in fabcf46

"short": "PROC. OF THE 9th PYTHON IN SCIENCE CONF. (SCIPY 2010)",

Publish 2017 proceedings papers in Figshare Collection for DOIs?

Hello all, this may have come up in conversation in past years (and I talked to @katyhuff a bit about this in Austin), but it would be nice to get the proceedings papers archived permanently (with DOIs) somewhere like Figshare.

Perhaps a Figshare collection could be created for all the papers? The past proceedings websites are all really slick so I don't propose getting rid of those, but this could supplement as a permanent archival for the papers themselves—the PDF links could be replaced with a link to the DOIs.

Wrong year being rendered on PDFs

Is the use of the year 2010 intentional in these lines? I believe it is causing the wrong year to be rendered at the top of the PDF (assuming it should be 2015).

Setting last author as corresponding author?

Currently, whatever author is listed first is the corresponding author. However, we would like to use the last author specified as the corresponding author. Will that be possible?

Wide (two-column) Tables

This seems to be a recurring theme for me. Can we get a tag/specifier for wide tables?

Thanks again for the quick response on the wide figures.

Best,
Mark

Required latex packages.

On a somewhat vanilla Fedora Linux system, the following packages are needed in order to build the example:

texlive-IEEEtran
texlive-everypage
texlive-draftwatermark
texlive-multirow

2008 and 2009 websites lack images

Trying to maintain the conference.scipy.org site, I noticed the following pages are missing images. Is there someplace to find the source?

http://conference.scipy.org/proceedings/scipy2009/
http://conference.scipy.org/proceedings/scipy2008/

make html breaks

cp _build/tex/proceedings.pdf _build/pdfs/proceedings.pdf 
python build_html.py
/bin/sh: 1: recode: not found
Traceback (most recent call last):
  File "build_html.py", line 29, in <module>
    html_from_tmpl(dest_fn+'.html', proc_dict, dest_fn)
  File "/home/sb/projects/scipy_proceedings/publisher/build_template.py", line 56, in html_from_tmpl
    content =  _from_template(src, config)
  File "/home/sb/projects/scipy_proceedings/publisher/build_template.py", line 24, in _from_template
    template = tempita.HTMLTemplate(open(tmpl, 'r').read())
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 131, in __init__
    self._parsed = parse(content, name=name, line_offset=line_offset, delimeters=self.delimeters)
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 823, in parse
    next_chunk, tokens = parse_expr(tokens, name)
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 869, in parse_expr
    return parse_for(tokens, name, context)
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 955, in parse_for
    next_chunk, tokens = parse_expr(tokens, name, context)
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 869, in parse_expr
    return parse_for(tokens, name, context)
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 955, in parse_for
    next_chunk, tokens = parse_expr(tokens, name, context)
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 854, in parse_expr
    return parse_cond(tokens, name, context)
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 893, in parse_cond
    next_chunk, tokens = parse_one_cond(tokens, name, context)
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 909, in parse_one_cond
    assert 0, "Unexpected token %r at %s" % (first, pos)
AssertionError: Unexpected token " if 'org' in member " at (12, 51)
make: *** [proceedings-html] Error 1
rm _build/tex/students.tex _build/tex/copyright.tex _build/tex/organization.tex _build/tex/title.tex

Using the format for generic open-revision publications

Hello, I have been trying to set up a system for scientific publishing with open accessible revision (as opposed to review!) in mind. For my (rather messy) current LaTeX-based solution please see https://github.com/TheChymera/OPR.Concepts-Guidelines-for-OPR .

The way the scipy proceedings are organized seems a far supperior approach, though. I would like to publish individual papers as separate git repos (so that someone interested in a specific paper can pull and revise it). For this purpose it makes little sense for me to have multiple papers under papers/ .

Any suggestions on how I could best reformat this so that I just have all of my stuff under paper/ ?

bibliographic data used in article html template badly

Bibliographic data (author's names, emails, and institutions) are rendered badly in the article html template.

In the toc.json file created by the build script, this data is represented for each article as (for example):

           "author_institution": [
                "Universidad de Valparaiso, Chile",
                "Advanced Center for Electrical and Electronic Engineering",
                "Universidad de Valparaiso, Chile",
                "Advanced Center for Electrical and Electronic Engineering",
                "Universidad de Valparaiso, Chile",
                "Universidad de Valparaiso, Chile"
            ],
            "bibliography": "",
            "author": [
                "Alejandro Weinstein",
                "Wael El-Deredy",
                "Stéren Chabert",
                "Myriam Fuentes"
            ],
            "author_email": [
                "[email protected]",
                "[email protected]",
                "[email protected]",
                "[email protected]"
            ],

This is then rendered to the template by looping through the lists associated with author and author_instituion, zipped together:

https://github.com/scipy-conference/scipy_proceedings/blob/master/publisher/_templates/article.html.tmpl#L5

If there are multiple institutions listed for any author, these lists will get out of sync and become inaccurate.

Instead, the authors field should be a list of objects with name, institution, and email fields. Then this data should be used in the template to create the expected result.

use LaTeX package that breaks urls on hyphens, for long urls in references

Long URLs in the reference section may not break appropriately into multiple lines, even when there are hyphens in the URL where it would be appropriate to break. In order to get these URLs to render properly, we need to use the hyphen option in the LaTeX url package:

\usepackage[hyphens]{url}

Thanks to @kyleniemeyer for this point

#205 (comment)

Fix Error in Mesa document

@katyhuff I'm taking the mesa conference proceeding and putting all the code into an ipython notebook to be used as a tutorial. I noticed the from mesa.datacollector import DataCollector line in the Data Collection section should read from mesa.datacollection import DataCollector

(datacollector to datacollection) should this be changed as a PR to be merged?

@dmasad @jackiekazil

make all breaks

sb@arcadia:~/projects/scipy_proceedings/publisher$ make all
rm -rf ../output/* _build/*
mkdir -p _build/tex
./build_template.py title.tex
Traceback (most recent call last):
  File "./build_template.py", line 7, in <module>
    import tempita
  File "/home/sb/projects/scipy_proceedings/publisher/tempita/__init__.py", line 295
    except SyntaxError, e:
                      ^
SyntaxError: invalid syntax
make: *** [_build/tex/title.tex] Error 1

wtf

PDFLaTeX error output when following README instructions

I've been following the instructions in the README and have gotten a PDFLaTeX error when trying to compile my (unedited) copy of the 00_vanderwalt paper. The culprit appears to be a missing file, paper_stats.json

This is a gist of the error and preceding commands, copied from my terminal:

https://gist.github.com/sbenthall/67d0a39d8c7b9efdd961

bibdervalt not rendering bibliography or citations properly

Ubuntu 14.04 rendering 00_bibdervalt using sh make_paper.sh gives me a pdf, but with no visible references section and [?] instead of a reference.

I've ran all the apt-get commands for latex packages listed in the README.

[proceedings] multiple institutions?

In the 2015 proceedings template and build system, are multiple institutions per author accepted/supported?

It seems to work, in terms of generating the correct footnotes for affiliations, but I'm getting incorrect footnote markers next to the names.

Example source:

:author: First author
:email: [email protected]
:institution: Home of Foo
:institution: Home of Bar

:author: Second author
:institution: Home of Bar

:author: Third author
:institution: Yet another place

and the rendered tex/pdf output:

...

Second author should have a single dagger, and only Third author should have the double-dagger.

Question re Publishing

Filling out paperwork here (needs tracking as Govt funds used). Is there a formal "Publisher" of these proceedings?

Paper built on server has different layout properties for body text font than local builds

Here is an image of what I mean. I thought our submission was within the 8 page limit because when built locally it is.

It looks like there might be a "leading" (space between lines) issue as well as a definite font size difference for both headers and the body text. But it is not a general typesetting issue because the title and the abstract seem to be rendered with the same spacing properties in both cases.

Also the smallcaps Scipy proceedings header is a serif font in the build server's version and sans-serif in the locally built version.

Not sure what these could be other than default LaTeX parameters that might differ between older and newer distributions. I'm going to guess that the server's is older than my local version, but I could be wrong.

Use archival link to video, not simply YouTube link

See #239 (comment)

Line number reported in error message is incorrect.

This one is quite hard to fix. Because we run the rst converter on processed rst, the line number it throws is different from the original line number.

I don't think it is possible to get the original line number. (Is there a #line instruction in restructured text?)

As a practical alternative, we may want to catch the error, and print some context information from the processed rst to help the authors in finding the error.

wrong *th in proceedings

https://github.com/scipy-conference/scipy_proceedings/blob/2014/scipy_proc.json#L8

If 2010 was the 9th.. http://conference.scipy.org/proceedings/scipy2010/
would this not be the 13th?

Use IPython notebook to write proceedings paper?

I am trying to write the proceedings using the IPython Notebook to write my paper for the SciPy 2014 proceedings, since I am not very familiar with reST (and since the IPython Notebook seems like a good tool for such a document for future reference...)

I have two questions:
(1) What is the correct way to include output from Python code (i.e. notebook output cells) in the proceedings?

(2) The reST conversion using

ipython nbconvert file.ipynb --to rst

produces output which is not recognised (apparently) by the SciPy format, e.g.

.. math:: a = \pm 2^e \times m.

which should be

.. math:: 

    a = \pm 2^e \times m.

Is there a good solution to this (except editing by hand)?

Allow building papers straight from Jupyter notebooks

Apparent python 3 incompatibility and possible PDFLaTeX error

In following the instructions after forking the repo, cloning into a local directory, switching to the 2015 branch, making a personal directory (papers/mike_pacer), moving the example paper into my local directory and then trying to run ./make_paper.sh papers/mike_pacer/ I get an error.

Specifically,

  File "publisher/build_paper.py", line 123
    print "PDFLaTeX error output:"
                                 ^
SyntaxError: Missing parentheses in call to 'print'
Error building paper papers/mike_pacer/. Aborting.

Which looks like it both had some kind of problem related to running PDFLaTeX, as well as an error having to do with a python 3 incompatible print statement in its error printing code(though this just happened so I haven't had an opportunity to investigate more thoroughly yet).

question: is the page limit 7 or 8?

The readme says 7, but the email said 8.

is this what I should do now?

Delay in publishing proceedings is unacceptable

I don't mean to be harsh, but this long of a delay in publishing the proceedings is simply unacceptable. If the conference wants anyone to bother with submitting a proceedings next year, or for the foreseeable future for that matter, the conference organizers need to step up and completely overhaul this procedure. Some people actually rely on this conference proceedings to get their results out in a published format--it appears that this was a mistake.

Unused 'location' field in 'sponsored students' list

In the conference metadata for the proceedigns, scipy_proc.json, there's a place for a list of sponsored students. Entries in this list have three fields: name, org, and location.

Generally speaking, the 'location' field is not used and the result is that the proceedings are published with a trailing comma after each sponsored students.

http://conference.scipy.org/proceedings/scipy2015/students.html

This should be corrected, making the location field optional or non-existent.

conference metadata

• list of sponsored students
• committee list
• reviewers list
• intro?

Link to video in bottom of paper, not top

See #239 (comment)

update master from 2016

Looks like the 2016 branch is currently ahead of master, but those commits are generic.

Can we sync up 2016 with master?

@sarostru @stefanv