List of hosting platforms which support iojs

[asci]

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

[snostorm]

I'd like this to somehow be on the site eventually but it is a little too early. I'd be nice to launch such a page listing several options. For example, I'd expect a service like CircleCI to work within a few weeks of NPM officially getting support (based on a chat I had with their support team on their turnaround times.)

For now I setup https://github.com/iojs/website/wiki/Projects--and-services-using-io.js as a starting point for collecting the content.

I'll leave this ticket open for others to review, but I'd say -- for now -- let's start collecting on the wiki so we have a starting point.

[Fishrock123]

Wiki seems like a good start.

[therebelrobot]

+1 to wiki

[julianduque]

+1 for wiki, just added travis to the list :)

[Fishrock123]

ping @iojs/evangelism I think we've had a lot more join, anyone able to help grab some from the weekly updates?

[mikeal]

The wiki is basically invisible, nobody looks at it. If we want to get real exposure for this stuff it needs to be on some kind of website. Perhaps it should be on an evangelism website though?

[blakmatrix]

@mikeal I think that is a great Idea! That definitely seems like the proper place, whether its languages or platforms or whatever, a single group needs to drive the effort of collecting information in order to get more exposure, the website serves a particular set of tasks, it shouldn't be expected to take on additionals like evangelizing certain things outside of those tasks/goals -- It'd be great if they did, but lets not make the assumption that that will happen.

[Fishrock123]

I don't understand why we would have more than one website...?

[blakmatrix]

evangelism.iojs.org or iojs.org/evangelism ?

[snostorm]

My vote: no no no. Think of this from an end user's perspective. They don't really care about our internal sub-divisions. They just want to learn about io.js. If they hit our site and start looking for resources, why are we taking them to yet another site? This will just be confusing and add more overhead for everyone.

One major purpose of the website WG (imho) is to provide the tech stack and an endpoint for our various WGs (i18n and otherwise) to publish resources under a common place.

Really, evangelism should just see us as one of their many publishing platforms. If the group want to start publishing articles like this we should adding the logical content divisions to the website. Then the i18n groups can evolve their versions of these articles too on the same platform. Would we expect each (interested) i18n group to start mirroring/hosting the evangelism-created content for their language themselves?

---

I'll rewind a bit. http://iojs.org/evangelism or perhaps more correctly http://iojs.org/en/groups/evangelism should exist. We probably should allow for a bit of a "landing page" for each group who wants one where they can post a their list of members, social media resources, how to contribute info, etc.

---

Regarding not using the wiki from a data collection standpoint: ya, that's fine? I guess my point a few weeks back is that we needed to first

a) scape together just enough info to justify putting a new article on the site
b) have somebody then volunteer to write it
c) PR + publish

The idea of me suggesting the wiki was so that internally, as a WG**, we could have an issue open like this and our contributors could go to the wiki article to help add notes prior to a & b above.

** this was pre-evangelism when the efforts like this were still somewhat combined.

---

Wait, was the whole idea of evangelism.iojs.org to be some sort of raw list of content needing creating or something? For the unpolished stuff? Like a wiki or something? Anyway, I would argue that it is still probably being coordinated mostly through GitHub so that might still confuse people.

[Fishrock123]

The website is here so people can put io.js stuff on it. It's made so we can easily add pages. We take care of primarily the technical part as a WG.

[blakmatrix]

@Fishrock123 The issue at the current moment is that we're trying to solve is getting end-users, WG members and followers visibility into what hosting platforms support iojs. The wiki was tried, seems that was a failure of sorts. That's when @mikeal chimed in and suggested that perhaps this information would be better served on an evangelism site. Evangelism is heavily invested in the end user. We want to see all the WGs grow and further adoption of iojs and excite people into contributing where they can.

What we are all having issues with is how to do that exactly, where is the line drawn for the website WG of additions by evangelism, build, i18n-, streams, roadmap, docker, tracing, etc. What constitutes as belonging on the website and not? An iojs evangelism website would presumably host content managed by the evangelism WG; an iojs tracing website would presumably host content managed by the tracing WG; an iojs build website would presumably host content managed by the build WG; an iojs streams website would presumably host content managed by the streams WG; an iojs i18n- website would presumably host content managed by the i18n-* WG... Hosting it here means the content would be presumably managed by x WG and the Website WG.

Where is the divide? Where would the Website WG draw the line, would it block certain content one WG wants to list? Would the Website WG be able to handle being a content nexus?

As @snostorm related, the end user doesn't care directly about our open governance model, they just want the content at the time they need it (indirectly: they will become frustrated by not having access to the info they need). Taking them to another site will add overhead, in the grand scheme of things perhaps this will become an issue or not, it's to early to tell but there is plenty of anecdotal evidence on both sides of the issue.

What would be necessary to add these "logical content divisions to the website" such that it'll be acceptable to each WGs own governance? What kind of consensus protocols need to be in place to facilitate that type of communication between WGs? Ultimately, can we/should we make something like this work?

[snostorm]

I think the wiki was only ever "tried" as a way to get people coming across an open ticket to contribute to it so we'd have enough content in place to promote it to a full published article one day. In that content's current state it isn't worth advertising to external users via any channel ;)

Anyway, I still want to circle back and say yes, the website's mandate is to help everyone publish however we can. Just like the Build WG helps other WGs with their release needs, hosting automation, SSL, CI, etc.

Would the Website WG be able to handle being a content nexus?

If it becomes an issue one day where the Website group is overloaded with content PRs we could always work with Build to make it so certain content namespaces in the site auto publish from changes external WG repos (as they push to their own master branches) just like pushing to Website's master branch publishes the main site now.

I think Evangelism + TC + Website + i18n (for website responsibilities) are a special case of where we should try and work together for content, yes. Guides, tutorials, updates, fancier release notes, etc. are all possible with what we have now in Website (design aside.)

By working together we can achieve a more consistent feeling across the project and avoid duplicating efforts.

[mikeal]

We're getting a little too far ahead of ourselves here.

IMO we should table this issue until there are a large number of hosting platforms that we need to be listing. Until then we can promote each new platform as it comes available through twitter and the weekly updates, as we have been.

There has already been a more substantial amount of time spent discussing this than it would take to do it. Doing it is actually easy, it just isn't a huge priority yet so let's put this to bed until it is.

On the topic of "do we have an evangelism (or other) website": We're mixing up "website" and "webpage" or "webpages" here a lot. We will eventually need a page that addresses, strictly, the promotion of io.js. Possibly multiple pages. Whether we present that as another "site" or a set of pages on the main domain is another discussion entirely and once we have the content we'll know a lot more about the best way to present that. How we build that site/pages (regardless of how it is "presented") could (and probably should) use the website toolchain unless there is a damn good reason not to since we would have to re-write a lot of stuff unnecessarily. Anyway, that's a discussion for another day.

[bnb]

This sounds like something the new docs WG can take care of - that WG taking care of things like guides/tutorials instead of just reference. Should I tag it as such?

[bnb]

This is an issue that can be handled by the Docs WG. I've marked it as invalid and docs to ensure its responsibility is handed to the Docs WG. If you want to discuss this issue, see nodejs/docs#10.