Consider using a blog platform for posts?

[jcbhmr]

Hello! 👋

This is a suggestion. Feel free to "transfer to Discussion" or whatever if this isn't right for an issue. 😊

I think that it might be worth consider either a) cross-posting the blog-like posts from https://containers.dev/guides to https://dev.to/ or another blog platform OR b) using dev.to or another blog-like platform as your CMS for posts.

My pro/con thoughts (my opinions)

Using something like dev.to would have the following advantages:

• Users can't open PRs for old posts. They stay frozen in time as you the author wrote them.
• Authorship is much more "traditional" and less "code-y". You have a few names and links at the top instead of commit history.
• Less friction to create new posts. You just click "+" in your dev.to or other platform and boom new post!
• More friendly for non-GitHub users (BitBucket, GitLab, etc) since it's a separate platform?
• Content is more "distant" from the implementation details and specification; it's a blog not a specification changelog chronicle!
• Designed for blog posting.
• Better Google SEO. dev.to posts seem (from my experience) to be much more Google-able. Even having just an RSS-feed mirror might aid SEO? Since one of the posts is titled "best practices", this would seem to be a worthwhile goal 😉
• Better subscription notifications. You don't need to re-implement an email listing workflow, just use dev.to or Medium's subscription/follow mechanism.
• Analytics. You actually get some kind of feedback system since dev.to (or Medium or whatever) was designed for blogging 😁
• Builtin RSS feed! The current RSS feed doesn't work. https://containers.dev/feed.xml Using a built-for-blogging system would hopefully solve this.

Using something like dev.to would have the following disadvantages:

• Other contributors would not be able to open PRs for old posts. They would become outdated over time.
• No commit-like history of contributor's contributions (if anyone else collaborated to make a post)
• Lose the extremely tight GitHub integration. Content is a bit more "distant" from the specification and implementation details.

As you may have guessed, I like the idea of having blog content separate from the "code content" (or similar code-y content) to use the right tool for the job. However, other users have used GitHub as the CMS and then mirrored to dev.to or other platforms with great success!
https://dev.to/aralroca/say-goodbye-to-spread-operator-use-default-composer-3c2j
https://dev.to/perssondennis/if-we-only-had-five-vs-code-extensions-4ge4
https://dev.to/srebalaji/branch-based-vs-trunk-based-development-557a
https://dev.to/emma/using-the-dev-api-to-add-dev-to-comment-counts-to-my-blog-3cd
https://dev.to/shaunchurch/optimistic-user-interfaces-a-good-kind-of-lie-1fek

I think the best reason to consider syndicating content elsewhere (the https://indieweb.org/POSSE philosophy) is better SEO for google-ability. If I search for "devcontainer guide", I get a dev.to article, not the official blog! 🤣

I think that creating such an https://dev.to/devcontainers organization and mirroring the RSS feed there is good idea.

You can create an organization and import an RSS feed! It's that simple!
https://dev.to/organization-info
https://dev.to/settings/organization

[bamurtaugh]

Thank you for opening this issue and including fantastic details @jcbhmr!

The points you list are definitely interesting. I think at this point, we've been sticking with containers.dev as it continues to be the "source of truth" for everything dev containers, including blog-like posts. We of course welcome folks to publish blogs in other spots too, including dev.to 😄. cc @craiglpeters for any additional thoughts

[jcbhmr]

Would you consider syndicating content from containers.dev to other platforms to get more SEO reach? 🤔 That's the biggest drive behind this idea.

[bamurtaugh]

I think that's a great point and something we'd leave to each author on an individual basis - we're more than happy for authors to share their posts wherever they'd like, but it's not something we'd intend to initiate or maintain over time (at least at this point).