Move blog from Medium to something we administer

[JasonWeill]

Today, Jupyter uses Medium as its host for the official Jupyter blog.

Pros of Medium:

• Generally reliable and well-known site with an ad-free business model
• Has email subscriptions and integrates well with other social media
• Provides post discovery features so that people interested in Jupyter, but not subscribed to our blog, see our articles
• Provides server-side reading lists, audio versions of articles (as a paid feature), and apps for major mobile OSes
• Provides statistics and analytics
• Provides a generally spam-free commenting experience
• Easy to write and edit posts using a web-based WYSIWYG editor

Cons of Medium:

• Run by a third-party company with a business model based on subscriptions, which it pitches to readers constantly, even though the Jupyter Blog's content is not behind a paywall
• Suggests articles by other authors, on other topics, adjacent to Jupyter's content; we have effectively no control over this, at least not with the plan that we use
• Has its own identity pool, requiring users to set up and maintain their own accounts
• Has its own permissions model, requiring users to request access to submit articles to the blog
• Does not allow articles to be coauthored; article bylines cannot be modified before or after publishing
• Basic formatting by design

Thoughts about migrating to a Jekyll-based blog solution, such as one using GitHub Pages?

Pros of Jekyll:

• Gives us complete end-to-end control over the blog's appearance and functionality, using open source software
• Gives us ownership of all posts in an open format like markdown, which is easy to migrate and back up
• Can be built and deployed using GitHub, using GitHub's existing identity pool and workflows (e.g., pull requests, actions, etc)
• Submission queue can be administered using GitHub pull requests, a more open process
• Allows for customization at the site and post level, offering richer formatting than what Medium offers

Cons of Jekyll:

• May require us to pay for hosting if we move off of GitHub Pages. Using Amazon S3 and Amazon CloudFront as a content delivery network (CDN), this is likely to cost under $1 per month. (Disclosure: I work for AWS)
• Requires users to write posts in markdown format, not necessarily using a WYSIWYG editor. Adding images, for example, is more cumbersome this way.
• May be harder to draft a post privately (although a private GitHub repo can be used)
• Requires blog maintainers to refresh the site's visual look from time to time
• As a static site, comments are not offered; we would have to rely on third-party social media, Discourse, Disqus, or other plugins for commenting. Screening comments for spam and Code of Conduct violations can be time-consuming.
• No built-in subscription or discovery model, beyond a basic RSS/Atom feed; blog authors or maintainers have to do their own promotion, such as by submitting blog posts to aggregators like Hacker News and Reddit
• No built-in statistics or analytics; we would have to build these ourselves, if we want them

[Carreau]

I fully support moving to to any platform where we have control over the data and make it easy to move to another platform later.

Historically my interpretation is that this has always been decided against/vetoed under the reason that "Non-technical people that don't how how to do PRs will be managing the blog" (which I personally don't find the be that much the case). And "it is hard for guest blog post".

I've personally always thought that reviewing PRs for blog post on GH would be much easier.

I believe there was some discussion at some point of Ghost (https://ghost.org/), and Gatsby, and that one of the limiting factors would be the work to export existing medium articles.

Also to add in Cons of Medium, you can add that it is currently login with twitter.
And Cons of jekyll, it's hard to embargo anything without disrupting the normal blog post flow.

[JasonWeill]

For new accounts, Medium does not use Twitter/X for authentication anymore; users can sign up with a Google account, a Facebook account, or a simple email/password combo. It does support Twitter for login, though, for people who enrolled using it.

[Carreau]

Sorry I meant we need to login as Jupyter using twitter account.

[andrii-i]

Another alternative for self-hosting is Sphinx (https://sphinx-intro-tutorial.readthedocs.io/en/latest/index.html#) as suggested/advocated for by @bollwyvl. Can also be used to host docs and API specs.

[minrk]

I believe there was some discussion at some point of Ghost (https://ghost.org/)

Our previous blog was ghost before medium, self-hosted on Rackspace. It was a bit janky, hard to review, and ~impossible for guest posts, IIRC, which motivated the move to Medium. It fell a little bit in a no man's land between developer-friendly experience of a static site on GitHub and a lower bar to entry of a hosted wysiwyg service like medium, somehow having a bit of the downsides of both. Export was easy, though.

I do think a static site with markdown posts via GitHub PR would be better for a lot of us. I'm not sure embargo is an impediment. Many of our JupyterHub team's posts have been drafted on HackMD because it's easier to to review/collaborate than medium, anyway, and only submit to medium when it's ready. The guest post problem is trickier, but there are various wysiwyg and/or side-by-side markdown editors. I'm not sure there's one that would support drag/drop image placement in a GitHub-built site, though. I think you need a hosted editor for that to work (I'd love to be wrong, though!). We might be able to use something external for a friendlier drafting experience when required, and then bring it into the site via regular PR.

Would be kinda neat if the Jupyter blog used a site that supported notebooks as posts...

[fperez]

Curious if @rowanc1 has thoughts on this from the myst toolchain perspective... It feels to me that our toolchain on that end is improving so much that we may have some new ways of thinking about this... Specifically I'm thinking of something backed by a repo with myst/md/ipynb support, but potentially an improved UI provided by the (today's or with future improvements) the jupyterlab-myst machinery.

Anyway, I don't quite have a concrete solution yet, just thinking out loud...

[choldgraf]

I am biased but also think it would be really cool if we could get a MyST-backed blog for Jupyter. It would be a nice way to dogfood that ecosystem, identify ways to improve it, and also highlight it for readers of the blog.

[blink1073]

Speak as (a) member of the upcoming Jupyter Media Strategy Working Group, I overall like the idea of using our own infrastructure to host the blog.

We'll need to consider:

• how much up front work it will be to set up
• how to support making it easier to handle things like inline figures - this has historically been a barrier for me personally to add images to my markdown-based docs

[fperez]

A while back @choldgraf asked about WYSIWYG Markdown editing on discourse, and while I found this tool there seem to be issues with it. At least a quick test made my "create notebook" icon disappear from the JuptyerLab launcher, so something isn't quite right :)

I'm just connecting these dots in case there's new progress on that front elsewhere - being able to offer a more WYSIWIG experience to authors could address some of the concerns with guest posts and those authored by folks who don't regularly work in raw markdown.

[choldgraf]

@blink1073 actually inline figures via code cell outputs are already possible via the jupyterlab extension

https://mystmd.org/guide/quickstart-jupyter-lab-myst#inline-expressions

So I bet it wouldn't be too hard to get this working for other kinds of figures for the MyST website theme.

This is the kinda reason I think it would be great to dogfood this tech - we can give ourselves the motivation to make improvements that others would benefit from as well 🙂

And I would love to see a wysiwyg style editor in jupyterlab (and vscode etc) for MyST. The workflow that I've come to like the most is Obsidian, which "reveals" markdown as you move the cursor over it.