Static Blog page

[therebelrobot]

As per the checklist (#25), we should look into the possibility of a static page for announcements

[Fishrock123]

More like pages. This will be reasonable with #22.

[Anachron]

You could use http://hexo.io/
Github-Page: https://github.com/hexojs/hexo

[therebelrobot]

This will need to be revisited after we solidify the build process.

[chrisjlee]

I'd like to help with this effort. Following.

I haven't used hexo yet. But it looks pretty sweet.

[mikeal]

I'm actually -1 on having a self hosted blog.

We should just put posts up on whatever we can get the most traction. We've been using Medium and it has worked quite well.

[timaschew]

what you mean with having a self hosted blog?

what about to add a build step where all articles from medium are fetched and converted to markdown files. result could look like this: http://timaschew.github.io/website/en/blog/
and we can add a note/link which refers to the origin medium article.

With this solution you don't need to handle the articles by hand. Just to start a build step which syncing the articles from medium and the iojs/website repo and you have a static generated blog.

[fhemberger]

@mikeal What about simply using GitHub pages with Jekyll? (The build process is fully automated on GitHub, so you don't even have to install any of the dependencies if you don't want to.)

Medium is problematic for the i18n teams, because at the moment, we have to scrape the posts manually, clean up the markup and translate it. And then everybody has a separate place/blog/website/whatever to post it to, which can cause a lot of fragmentation.

We could have the static site (as it is now) with all the language versions in sub-folders still being entirely in markdown. The same would be true for the blog posts. By using categories, we could also set up various RSS/Atom feeds (e.g. all blog posts, releases/announcements only, etc.) also for every language.

[therebelrobot]

It would be possible to even have a blog/ folder in every content/<lang> folder, and work the build process around it to build it properly? This should also be added to the agenda for tomorrow most likely.

[timaschew]

What about simply using GitHub pages with Jekyll? (The build process is fully automated on GitHub, so you don't even have to install any of the dependencies if you don't want to.)

This doesn't fit into the current build process. It means the blog needs to be located under a extra repo -> extra fragmentation.

Medium is problematic for the i18n teams, because at the moment, we have to scrape the posts manually, clean up the markup and translate it.

With my suggestion, there is nothing problematic, because everything would be automated, except the translation which never can be done automatically without a high quality translation.

[mikeal]

I don't think it is too hard to do this technically but I think it's a bad idea just in terms of messaging and building community.

We should post wherever the most people will see it that are interested. For the communities forming around other languages this is even more important since we have no idea what will reach the largest audience in their native languages.

We didn't build our own twitter to send out small updates, we shouldn't build our own blog for basically the same reason.

[mikeal]

@fhemberger we're building all posts in GitHub issues using markdown prior to posting on Medium now so this shouldn't be a problem. Here's last weeks and this weeks issues for the weekly updates:

• Evangelism: Weekly Update Feb 13th #122
• Evangelism: Weekly Update Feb 20th #188

[fhemberger]

@mikeal How about the "Publish (on your) Own Site, Syndicate Elsewhere" approach? Use the own website as starting point for content, then syndicate the posts to Medium, Tumblr, Facebook, whatever? I'd personally prefer it so you don't make yourself too dependent on a single content silo. Using canonical meta tags, this is also fine for search engines.

[Fishrock123]

As discussed, medium is working fine. Linking to medium is starting to be done, and I think that's about all we need for the future. (Saves us a bunch of work honestly.)

[snostorm]

Ya, some content will naturally continue to develop on and off the site and we can chose to bring it in as time progresses. No rush on this. If the need is eventually there, this will pop up again as a new issue.