Roadmap/wish list for next major release

[dfm]

Since @rodluger has moved on to bigger and better things (🤖🚗), I've taken over maintenance of showyourwork, and wanted to start brainstorming ideas of major outstanding issues that will be important to address in the upcoming releases.

My overall goal is to make showyourwork less opinionated and invasive. I would like it to be easier to integrate showyourwork into many different workflows, rather than having showyourwork be the workflow that solves everything.

Here's a working list of some of my ideas and wish list:

• Make the formatting changes opt-in: A constant struggle that we face is that showyourwork is very opinionated about formatting, and getting it up and running with a new TeX classfile always takes a fair amount of hacking. While I think that the marginicons and other branding are a nice feature of the published papers, I'm thinking it might be better to allow for different workflows. For example, it would be nice to be able to use the showyourwork infrastructure to write and build the paper, but then only include a link to the specific version of the source in the text, rather than linking from each figure. Maybe we could come up with an interface for emitting a .tex file during the build process that has the required information for each figure such that we could support external showyourwork "styles" that could be explicitly included when building instead of the current hard-coded approach.

• Links at publication shouldn't be to GitHub: As discussed here and in various offline conversations, it's not ideal for the final published paper to include fragile links to GitHub. Instead, it might be preferred to link somewhere more permanent. If that more permanent place is a Zenodo DOI, then I don't think we'd be able to link to individual scripts, so maybe we want both. At the very least, we should have a workflow in place for collecting and publishing all the source code along with the generated figures and .tex files to post to arXiv, and/or Zenodo. The steps to pre-register a DOI could be a tutorial, rather than an explicit workflow.

• Refactor support for external services: As discussed here, right now, support for things like Zenodo and Overleaf are pretty tightly integrated into the core operation of showyourwork, making it somewhat awkward to update them, or to add support for new services. I bet it's possible to design some sort of plugin or extension framework that would support these as use cases, and allow us to make showyourwork a little less opinionated.

• Do away with the prep workflow and \script macro: A major user-facing change I'd like to make is to remove the custom \script TeX macro, and move the definitions of all scripts to the showyourwork.yml and Snakefile files. Being explicit about dependencies like this has a few benefits: (1) it means we could get rid of the preprocess call to snakemake which is just there to work out the required dependencies for each figure and add them to the config, and (2) allows for more flexible workflows (e.g. multiple scripts that each generate subfigures for multiple figure environments; this might sound contrived, but the first draft of this paper had to be changed a lot because that's what we wanted!). I don't think this would make anyone's life harder, but it would be a breaking backwards incompatible change. Edited to add: I think we would still be able to add the correct marginicons, etc. even after such a change because our workflow knows compute all the data dependencies, we just need to figure out how to expose them to the TeX file.

• Loosen integration with GitHub Actions: As written, showyourwork is very tightly integrated with GitHub Actions, which is interesting and cool, but probably isn't sustainable in the long run. I think it's worth thinking about how we could be more agnostic about the specific continuous integration system.

Please feel free to add thoughts/ideas below!