Blog post for the Jupyter blog?

[choldgraf]

Hey all - how do we feel about making a blog post for the Jupyter blog? (https://blog.jupyter.org/)

I think that this project is in-scope enough that's it's reasonable to post to this blog. However, I think the biggest question is how we can use a post like this to drive attention to the project.

For example, if we wish, should we use it as an opportunity to announce early prototypes of tools? Or should we keep it abstract and at the project level (such as https://ebp.jupyterbook.org/en/latest/updates/02-25-2020.html).

And more generally, how do folks feel about us posting updates about our tools in general? I have held off on making any major announcements about it, beyond reaching out to our close collaborators. But at some point we want to drive more attention to these tools in the hopes that they gain adoption and development.

[jstac]

Hi @choldgraf , I discussed a blog post with @mmcky and @chrisjsewell a couple of days ago. We all felt that it would be better to wait until we can point to better outputs. In particular, we think it's better to wait until we can (a) hook the different parts together to generate outputs corresponding to cell inputs and embed them in a web page, and (b) ensure that it's sufficiently easy to install that people can have fun playing around with it.

I know there's a tension between waiting and getting people involved from an early stage, but perhaps the right balance is when we have (a) and (b) but no more.

How about we plan on a blog post at the end of the month, and strive to have (a) and (b) done by then?

[jstac]

This post is popular and might be interested in adding our blog post when we're ready.

[chrisjsewell]

We all felt that it would be better to wait until we can point to better outputs

Yeh, the 'fear' is that people will get a bad first impression if they try out the tools too early in development (when all the functionality is not there), then never try it again.

[choldgraf]

makes sense to me. I think we want to make sure the functionality is there, though also that the package isn't so well-baked that it's hard to incorporate feedback from users. E.g. now that the myst-parser is in "alpha", who should we share it with to get testing and feedback?

[jstac]

We're getting a reasonable amount of testing from @mtiley, @mmcky, @AakashGfude and @najuzilu. Perhaps @gregcaporaso and his team might be willing to convert some documents?

Beyond that I don't know the right people to ask.

[choldgraf]

not to mention @rossbar - I've just found that it's better to trickle out features/projects/etc rather than have one gigantic press release all at once. Better to build momentum so that more people are paying attention when a "big announcement" comes.

[gregcaporaso]

I'm planning to do some work with Myst before our next call. I'm thinking I might try to build IAB using Sphinx and Myst, since it's already written in Markdown, and see what kind of issues come up if any. Does that sound like a useful test?

[choldgraf]

@gregcaporaso totally - I am also working on improving https://github.com/ExecutableBookProject/cli, which wraps the build system in a CLI to make it (hopefully) quite easy to build. I could try to put some cycles into improving the documentation there, if it'd make it easier for you to demo it.

Otherwise, you can also just roll your own Sphinx site with MyST-NB as an extension, and it should parse the notebooks (or markdown files) just fine.

[gregcaporaso]

@choldgraf, your call on whether it makes sense for you to focus on docs at this stage. I'm happy to try to figure it out with what exists now (eg start with the cli and fallback to the sphinx extension) and let you know if I'm running into issues.

[choldgraf]

Sounds good, I'll try to improve it a little bit with some docstrings etc, then I'll send you a link and ask you to give it a shot?

[jstac]

Please CC me too.

[choldgraf]

done! executablebooks/cli#16

[chrisjsewell]

consider it blogged