A RSS or Atom feed for new releases and/or announcements would be very welcome (unfortunately feed readers don't yet understand JSON). Could be part of a blog (#68) or something else (#67?).

We need a policy for closing/fixing PRs that have merge conflicts. see #24-comment-70226567. @snostorm suggested we close after some sort of X day policy. First maybe tag the author to try and rebase/conflict resolve before closing?

Hi guys, I would like a spanish version of the site, docs, etc... please give me feedback

I was wondering if we should expand the site a bit, maybe including an FAQ or a copy of the irc logs, make it more of a one-stop for all things io.js?

I've got time this weekend to work on this, I just want to make sure it'll be needed/wanted if I expand it a bit.

Inevitably, io.js packages will be created on popular platform-specific package managers. Should the website attempt to catalog these? For example, the mongodb download page does this https://www.mongodb.org/downloads#packages . The (much more verbose) Postgres site also lists package distribution options, broken out by platform, e.g. http://www.postgresql.org/download/macosx/

The /sh_main.js and /sh_javascript.min.js scripts result in 404s:

$ curl -sSLI https://iojs.org/sh_javascript.min.js

HTTP/1.1 404 Not Found
Server: nginx/1.4.6 (Ubuntu)
Date: Wed, 14 Jan 2015 10:23:08 GMT
Content-Type: text/html
Content-Length: 177
Connection: keep-alive

$ curl -sSLI https://iojs.org/sh_main.js

HTTP/1.1 404 Not Found
Server: nginx/1.4.6 (Ubuntu)
Date: Wed, 14 Jan 2015 10:24:22 GMT
Content-Type: text/html
Content-Length: 177
Connection: keep-alive

would be nice to be able to do something like GET http://iojs.org/download/latest/iojs-latest.tar.gz and maybe a semver version like ~1.0.2

Hi there,

I think for people changing from nodejs to io.js and also new beginners it would be good if we change the name docs with api.

It's simply not docs, since the only thing you can do there is learn about the API and I would expect docs to have tutorials and guides, not just the core API.

Comparisment to nodejs:
http://nodejs.org/ has a link to http://nodejs.org/documentation/ with name docs
This page has a link to http://nodejs.org/api/ with name API Docs.

In the next step we could create a overview page of different documentations including api, tutorials and more.

The website team is currently undertaking two tasks: messaging and website development.

Over the last week it has become clear that io.js needs a team that is just working on messaging and evangelism. I can't even keep up with all he requests for speakers and podcast interviewees. In the last week we've also gain a twitter, G+, youtube and facebook pages/accounts.

Having a fork is confusing enough, we need to build simple messaging and stay consistent across all these channels, especially in these first few months, if we want to continue to grow the user base and gain even more contributors.

What I would like to do is break off the messaging and management of social media in to an evangelism working group. This group would then work closely with the website team to update the messaging and coordinate any changes in the messaging. The website team would then be free to focus on the site functionality, content and design.

See nodejs/node#304 & nodejs/node#302

Critical

• Better design
• Static blog for announcements #68
  • some sort of changelog integration?
• docs / linkage nodejs/node#297
• Updated FAQ
• ES6 on io.js

When possible

• Release page that is updated on release and nightly build #67
• Better site navigation
• Changes since node 0.10 opted for link to CHANGELOG.md

Please edit this to fill gaps / etc as necessary.
cc @mikeal @chrisdickinson @rvagg @zeke

Given there's a lot of questions coming in on IRC and the mainline repo, we should probably add a section to the FAQ (or our first "guide" article) about different ways to install io.js, especially with regards to having it co-exist.

Methods to discuss (in no particular order):

• Why we stomp node and symlink it (npm, etc.)
• A list of supported package managers like nvm, n, etc. (once they have support)
• The n "workaround" of manually extracting the tarball as 1.0.1
• Running from the (extracted) pre-compiled tarball for your OS
• Building and installing to a new --prefix location
• Using $PATH to point at some of the above options

Ongoing reference to tickets discussing this issue:

• nodejs/node#376
• nodejs/node#429

MEETING POSTPONED FROM JAN 26th
Monday, Feb 2 at 19:00 UTC - Your time (Wolfram) | Your time (timeanddate.com)

Public YouTube Link: http://www.youtube.com/watch?v=SBJaXUA0lSY

Meeting Minutes Doc (to be added as a PR after the meeting)

Homework:

• select time on the 2nd for meeting
• link to help with timezones
• link to Hangout On Air
• link to committee minutes Google Doc, and volunteer to take minutes

Meeting Agenda

Previous Meeting Agenda

Matching or Diverging from io.js organizationally

Governance #81, Licensing #1, Contributing #69, Team Structure #19, Evangelism Team #82, IRC #65, Closing/Fixing Policy #76, Helping users properly report "website" Bugs/Issues #55

Build & Site Improvements

Pick a build system #22, i18n #33, Downloads, Release page (dynamic) #67, latest / semver links #80, Blog / announcements (page/section) #68, Feed for releases & announcements #79, List of supporting host (article/FAQ) #73

This Week Agenda

• #33, #22 - Status of i18n and build process
• #83, #109 - Social Media
• #84 - Hosting, build process README
• #92, #108 - Stability / helping users test io.js, describing "unstable"
• #91 - Device / Browser Coverage
• #99 - taking on API documentation
• #106 - IRC vs. Gitter vs. Slack = Battle Royale!

After:

• PR a copy of the committee minutes (with a link to hangout) in to the project

Heya,

Per the last TC meeting I've been reluctantly put "in charge" of the website.

After taking a quick look through the Issues and PRs I can see that we do need an owner/facilitator and, for the time being, that has fallen on me.

My immediate plan is to get something up that we can use for the launch next week. After that I want something in place that is easily updatable for each weekly release.

From there I'm going to reach out to proper designers to get involved and once we have some experienced people around I want to hand over the this owner/facilitator role to them.

Unless there are any strong objections I'll be merging the redesign PR and use that as a starting point.

As discussed during #59

• See #18 for some of the "how it works" stuff
• Most of this lives (externally) https://github.com/iojs/build/tree/master/setup/www

Rod already tweeted about how iojs was downloaded 100k times.
Can we open up aggregate download stats with download counts, file, platform, version, continent etc.?

The first thing people see when they go to iojs.org is "JavaScript I/O", then the current version number, then the disclaimer "(Unstable*)"

While this is true, it's also a bit of a cop out and doesn't help someone make a decision of whether or not to spend more time investigating io.js, which of course we want them to do, while being aware of its suitability to their needs.

I really like what rethinkdb has done on their page, breaking the amorphous idea of "stability" into a matrix of particular concerns, with a brief plain-language note on each:

http://rethinkdb.com/stability/

Migrated from nodejs/node#365:

Someone linked me to your project site today so I thought I'd take a look. The first thing I read was "io.js is an npm compatible platform originally based on node.js™" which confused me and I had no idea what this meant. What does "npm compatible platform" mean here? Is PHP a "Composer compatible platform" and is Python a "PyPI compatible platform"?

It would have made much more sense if it said "JavaScript runtime" or something like that. Perhaps "io.js is a JavaScript runtime with a Node.js-compatible API".

Relates to #53 - there's a couple issues on the core repo because that is the only place we direct them to for issues.

I'd love to see iojs.org move to TLS.

https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

https://wiki.mozilla.org/Security/Server_Side_TLS

Monday, Jan 19 at 19:00 UTC

In your local time zone:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=io.js+Website+Working+Group+-+Meeting+%231&iso=20150119T19&p1=1440&ah=1
• or http://www.wolframalpha.com/input/?i=7pm+UTC%2C+January+19%2C+2015+in+local+time

Homework:

• link to help with timezones
• link to Hangout On Air: https://plus.google.com/events/cgr2earsvuit8c05ljibbfqmkrk
• link to committee minutes Google Doc, and volunteer to take minutes

Meeting Agenda

Matching or Diverging from io.js organizationally

• Governance #81
• Licensing #1
• Contributing #69
• Team Structure #19
  • Evangelism Team #82
• IRC #65
• Closing/Fixing Policy #76
• Helping users properly report "website" Bugs/Issues #55

Build & Site Improvements

• Pick a build system #22
• i18n #33
• Downloads
  • Release page (dynamic) #67
  • latest / semver links #80
• Blog / announcements (page/section) #68
  • Feed for releases & announcements #79
• List of supporting host (article/FAQ) #73

New issues (as a result from the meeting)

• #83 - Social Media
• #84 - Hosting, build process README

After:

• PR a copy of the committee minutes (with a link to hangout) in to the project

Was reported to me in IRC that the #io.js logs aren't logging the 16th (today).

http://logs.libuv.org/io.js/latest

@bnoordhuis is this intentional? I thought they were real-time but I'm not sure.

Not sure if the former is possible.

Should we copy the io.js TC governance entirely or are there good reason to diverge?

Soon, the project will need more than 1-2 pages and a consistent look. With that we'll likely benefit from some sort of build process we can document for contributors in the project's ./README.md.

My recommendation is the builds (for now) happen locally with the static output committed in to the master repo, to support the build process already in place via #18. Later we could work with the build team to automate some things here.

If you take a look at https://www.staticgen.com/ there's a list of static-site generator tools we can pick from. Note, there is an option to filter it to only the JS-based projects (I couldn't hyperlink the filtered list directly.)

Some of the top projects by Github popularity/forks (with 2.1K - 3.8K stars each) include:

• http://hexo.io;
• http://brunch.io;
• http://metalsmith.io;
• http://harpjs.com; and
• http://assemble.io/

I need to refresh myself on these projects as it is been a couple of years since I've needed to chose one and the list has grown considerably, but overall I'd recommend us choosing a solution which offers a few simple page-template variations combined with markdown or a dead simple alternative for content.

A simple way of writing content (say in GitHub-flavoured markdown) will make it VERY easy for contributors to help us build guides, version release notes, open governance/contribution articles, etc.

Thoughts?

I just bought an SSL certificate. Would like to setup a website for us, what should I use for hosting? What to put there?

Moved from: nodejs/node#221

Just like we're doing for build and streams, we need a website team with some form of structure. Could we start some discussion amongst interested individuals about how this might work. Ideally there should be semi-regular broadcast Hangouts On Air that we can put on the iojs calendar and let others tune in to (real-time or the recordings), so it needs a facilitator of some kind to make that happen.

The governance guidelines for io.js allow for other parties to occasionally join in on TC meetings, we already have that for the build project but I'm going to suggest that the TC regularly have non-TC representatives of streams and website on too.

There is a lot of feedback today that our website copy is doing a bad job of explaining to outsiders what io.js actually is.

This is to track some PRs relating to doing a better job of explaining this, sooner than later, as we have a lot of traffic right now.

• Add a link to this repo for people to help with content, spelling, etc. #55 (blocked by #57?)
• Home page: better "blurb", explain 1.0.x semver #50
• FAQ: improve "what is io.js" #54
• FAQ: adds info about semver #54
• FAQ: link to projects, tools which use/support io.js ? - could be premature. Collecting in Wiki
  • heroku
  • Atom editor
  • n, nvm (soon)

Might be a good idea, just to keep the core channel free for core stuff.

There have been a few +1 for this idea in other threads, especially now that the site isn't hosted on GitHub pages. We might as well break away from that (where is it hosted) confusion sooner than later, and before we start linking to this repo from more public places.

What sections should we have in the FAQ page? We currently have:

• What is io.js?
• How can I contribute?
• Where do discussons take place? (spelling needs fix)
• What is open source governance?

Possible additions include:

• What is the relationship with Node.js?
• When will io.js be released?
• Does io.js have a logo?

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

We should set up a doc outlining how we are going to accept new pull requests, as well as outlining contributing to specific parts of the site, like i18n (see #33).

Prior to release preferably, so something within the next couple of days, simple is good IMO.

See https://iojs.org/download/nightly/v1.0.0-nightly20150110a32b92dbcf/doc/api/ (and in each nightly from now on). It's got "Node.js" and "Joyent" all over it. It would also be nice if they were more self-contained, without all the links to the other stuff hosted by nodejs.org.

Templates and styles are all in https://github.com/iojs/io.js/tree/v1.x/doc and you can generate docs with make doc (it'll need to build the binary first because it needs it for generation).

/cc @mikeal @Fishrock123 and anybody else who might want to put their hand up for this task.

Which browsers should we support in our code, which devices, etc. In reference to #89 . A short list we would need to decide coverage for would include

• Browsers
  • IE (6, 7, 8, 9, 10, 11)
  • Spartan (when available)
  • Firefox (and how many versions back)
  • Opera (and how many versions back)
  • Chrome (I think this is a given, but also how many versions back)
• Platforms
  • iOS - (browsers, versions and which devices)
  • Android - (browsers, versions and which devices)
  • Windows
  • Mac
  • Linux

WG: feel free to comment below or edit this thread with a 👍 or 👎 for voting

We should also document somewhere in our website docs the final list we decide on, so we can have a standards system set up (no merge accepted without proper cross-browser support, etc.)

• Facebook Group admins
• Google+ Group admins
• Twitter (ugh, any way to share access short of the password?)
• Other...?

Inspired by https://github.com/seegno/io.js/wiki/The-state-of-ES6-on-io.js via nodejs/node#251

https://iojs.org/es6.html

Which ES6 features ship with io.js by default (no runtime flag required)?
Block scoping
let
const

Lexical Declaration syntax is there, but the semantics are wrong and authors should be warned. Example:

{
  let a = 1;
  const b = 2;
}

Result:

  let a = 1;
  ^^^
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode

This is not correct ES6 semantics—there is no strict mode limitation.

I can write up a patch, let me know.

I've been amping up what we currently do on social media. I'm going to document it so that people can jump in to help that aren't just me :)

The current channels we have are:

• Twitter (@official_iojs)
• Facebook (https://www.facebook.com/iojs.community)
• Google Plus (https://plus.google.com/u/0/b/101986715696875566237/101986715696875566237/about)

We're working on a better vanity URL for G+ and taking over @iojs on twitter (which is a dead account).

A few high level goals:

• Create a bi-directional relationship with the broader community.
  • Post links to interesting developments in the project like issues that are of broad interest, etc.
  • Respond to any issues or complaints about iojs or nodejs (currently using Sprout Social to track all of that)
  • Favorite and retweet posts from the community
• PMA (Positive Mental Attitude)
  • Never post anything negative or respond negatively.
  • When people complain, kill them with kindness :)

The more time I spend in the feed the more I think that having such an active presence could be what brings the broader community in to the project. We can use this presence to reach end users and the front end developers we've traditionally lacked engagement with.

I'm still exploring and experimenting with tooling. All the good tools cost some amount of money and are either per-user or have tiers with user caps so it's going to be hard to have a lot of people helping out :(

Let me know about anything you'd like promoted or if you feel like there's something we should be doing that we aren't yet.

io.js is a compatible spork* of node

(tagline)

io.js contributions, releases, and contributorship are under an open governance model.

We intend to release, with increasing regularity, releases which are compatible with the npm ecosystem that has been built to date for node.js.

(description)

Discussion appreciated. :)

See also: nodejs/node#3 and nodejs/node#24

Can anybody provide page with list of those platforms?
Or just contribute a list here?

We should make a setup with #22 where we can have language-specific content (markdown) files that build to /lang/ directories we can serve.

cc @laosb @snostorm

So we need to pull together a navigation design for the iojs.org site, make sure that we can add additional links and pages as needed in the future without it looking like a potato.

Anyone with shiny design experience want to take a crack at it?

I guess we could go with a free bootstrap theme or something, though I don't know how you all feel about libraries and whatnot.

I guess we need to decide a few things:

• what JS libraries we want to include (jQuery, Angular, Browserify, etc.)
• what CSS libraries/preprocessors to use (Bootstrap, Foundation, LESS, SASS, etc.)
• what we want to do with navigation
• if we want to use a template
• what to do about branding (logos, taglines, etc) while it's still being discussed

Judging by the continuous stream of confused 'what is io.js?' and 'why should I use io.js?' questions in the IRC channel, I think it would be good if the home page had a section or link that explains:

1. The relation ship to joyent/node; why does io.js exist when node.js exists?
2. Why should I (generic J. Random Developer 'I') use io.js instead of node.js?

I have some ideas on what 1 and 2 should like but I'll happily defer to the people maintaining the website.

It doesn't have to be a large section, just a little something that gives people the right idea what io.js is about.

It may be useful to add an IRC primer into the FAQ so if we get devs who don't know how to use it (which are many), they can have a simple walkthrough on how to connect via a native client on their OS.

Emphasis on simple, however. A large IRC doc would be way outside the scope of the FAQ. At least IMO.

• all the TC members
• non-tc administrators (i.e. rvagg)
• all the working groups (website, streams) and significant projects (build system, if there's no working group for it) and the people involved
• each person's purpose/role/status in the context of each WG/project as well as iojs as a whole
• any leads of anything
• who to contact to get involved with each working group or project
• link to the main repository for each project/working group
• link to a point of contact for each person, i.e. twitter

also, maybe add something about https://github.com/node-forward/mentors?

Someone should test this to make sure I'm not telling horrible lies, but I am pretty sure that in V8 4.1.x classes and enhanced object literals are back under staging and so we can add them to the "Which ES6 features are behind the --es_staging flag?" section

(also while I'm here it might be good to change the "E.g. output" from 3.31.74.1 to the latest? Or just remove it.)

As per the checklist (#25), we need a release page that is updated on release and nightly build. Maybe a page that dynamically scrapes from github? It'd also be nice to have a rolling most-recent nightly download link directly on the main page.

@ruimarinho presented an interesting idea in his comment that perhaps there could be greater growth in usage if moved to slack (which can be connected via IRC if users want). It provides a good interface and is easier for non-technical users to participate in discussion.

I'm not for or against currently, wanting some collaborator input, see what everyone thinks. Also to make sure that the PR on scrollback is more focused on that issue.

Original Comment:

... a cool idea from @rauchg and his experience with a public Slack community. See https://github.com/rauchg/slackin.

If this WG is interested, I'd like to explore having it take over ownership of the documentation tooling for io.js. There's a natural intersection of concerns: localization, HTML generation, hosting, versioning, and the desire for smaller, sub-working-groups to be able to use the tooling provided.

While the docs themselves would still live in iojs/io.js; out/doc would be generated by whatever tool this WG deemed fit, whether it was custom built or a separate project. The tool would have to be a good basis for documentation going forward, and should support:

• At least the same level of quality for API docs.
• Documentation not tied specifically to a single API – that is to say, while we largely succeed at reference material, we fail at providing tutorial and overview docs.
• The ability to switch between versions of the docs.
• The ability to author and switch between localizations of the docs.

Things I'm not super interested in supporting via this tool:

• Directly editing non-human-oriented authoring formats (i.e., JSON).
• Generated API docs (like JavaDoc).
• Doctests.
• Type annotation.

Is there interest in this? The concrete steps going forward are to fully rip the existing tool out of the makefile, and point the makefile at the doc-tool repo instead.