iclr-blogposts / 2023

DO NOT FORK OR MAKE PRS TO THIS REPO! Please do this with the staging repo: https://github.com/iclr-blogposts/staging
https://iclr-blogposts.github.io/2023/
MIT License
1 stars 40 forks source link

2023/blog/2022/distill-example/ #5

Open utterances-bot opened 1 year ago

utterances-bot commented 1 year ago

Sample Blog Post | ICLR Blogposts 2023

Your blog post's abstract. This is an example of a distill-style blog post and the main elements it supports.

https://iclr-blogposts.github.io/2023/blog/2022/distill-example/

Velythyl commented 1 year ago

Wow!! You can even leave Markdown comments?!? Amazing!! 🥳

fabianp commented 1 year ago

What is the recommended way to attach a jupyter notebook to the submission?

busycalibrating commented 1 year ago

Hmm we didn't think of this - the simplest solution seems to be to export the notebook to markdown or HTML, and potentially provide a colab link as well? The concern I have with colab is that it can be modified by the user at any point, so ideally we'd have some sort of controlled google account for the blog track which we import all of the colab notebooks to. I'll ping my colleagues and see what they think, but how does that sound to you?

fabianp commented 1 year ago

exporting to html sounds good. Linking to a colab seems more problematic because of anonymization issues - it displays the google account of the creator

busycalibrating commented 1 year ago

Also a very good point!

Velythyl commented 1 year ago

I would suggest converting to markdown and including the cells you want in your blogpost. You can also include the actual notebook as an asset to your blogpost and link to it so that the users can download it. @fabianp

fabianp commented 1 year ago

Thanks. My issue is precisely that I'd like to avoid having all the code with the blog post. Adding it in the assets sounds good, but in which subfolder? I don't see any assets/code/ or assets/notebook . The closest is assets/js but that doesn't feel right

Velythyl commented 1 year ago

Ah, good point. I'd say put it in assets/html. It's good enough for now; if we need to clean things up later, we'll do so after merging PRs