Giter Site home page Giter Site logo

evangelism's Introduction

Evangelism

What does the Node.js Evangelism WG do?

The Evangelism WG creates promotional materials, brings discussions to a wider audience, and attemps to grow the community through positive, supportive messaging.

Why should you contribute to the Evangelism WG?

The Evangelism WG tries to bring more people into Node, and add to the experience of the ones that are already in it. If you are interested in social media, identity, messaging, writing, or communication, you could be a valuable asset to the WG.

How to get involved!

There are lots of ways to contribute to Node.js. If you are interested in contributing to Node.js evangelism specifically, feel free to join in the conversations, comment on and create issues where you see fit, submit pull requests if something can be improved, and help others get started. You don't have to be a member of the Working Group to pitch in!

Governance and Contributing

The Node.js Evangelism WG has adopted the core governance and contributing policies of Node.js.

You can view them at:

GOVERNANCE.md
CONTRIBUTING.md

The Evangelism WG is chartered by the Node.js Community Committee.

Evangelism WG Members

evangelism's People

Contributors

amiller-gh avatar bnb avatar danielkhan avatar davidfekke avatar diagramatics avatar dotproto avatar gioyik avatar gitter-badger avatar joel7871 avatar jsynowiec avatar julianduque avatar jungminu avatar mikeal avatar minaorangina avatar msmichellegar avatar rosskukulinski avatar subfuzion avatar tgfjt avatar thefourtheye avatar tierneyc avatar trott avatar vdeturckheim avatar vjk3 avatar watilde avatar williamkapke avatar yosuke-furukawa avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

evangelism's Issues

Evangelism: Weekly Update March 13th

io.js 1.5.1 Release

On Monday, March 9th, @rvagg released io.js v1.5.1. The complete change log can be found on GitHub.

Notable changes

  • tls: The reported TLS memory leak has been resolved via various commits in this release. Current testing indicated that there may still be some leak problems. Track complete progress at #1075.
  • http: Fixed an error reported at joyent/node#9348 and npm/npm#7349. Pending data was not being fully read upon an 'error' event leading to an assertion failure on socket.destroy(). (Fedor Indutny) #1103

Known issues

  • Possible remaining TLS-related memory leak(s), details at #1075.
  • Windows still reports some minor test failures and we are continuing to address all of these as a priority. See #1005.
  • Surrogate pair in REPL can freeze terminal #690
  • Not possible to build io.js as a static library #686
  • process.send() is not synchronous as the docs suggest, a regression introduced in 1.0.2, see #760 and fix in #774
  • Calling dns.setServers() while a DNS query is in progress can cause the process to crash on a failed assertion #894

Community Updates

Upcoming Events

  • NodeConf tickets are on sale, June 8th and 9th at Oakland, CA and NodeConf Adventure for June 11th - 14th at Walker Creek Ranch, CA
  • CascadiaJS tickets are on sale, July 8th - 10th at Washington State
  • NodeConf EU tickets are on sale, September 6th - 9th at Waterford, Ireland

Globalize date formatting

I noticed that the date format we're using for weekly updated is MM-DD-YYYY (PR #12). Given the global reach of io.js and Node.js, I'm concerned that this date format is too US-centric.

According to the Date format by country article on Wikiepdia, MM-DD-YYYY format is only used by 6 countires. The second most common format is YYYY-MM-DD (28 countries). Globally, the most commonly used date format is DD-MM-YYYY (124 countries).

I propose that in documents we adopt DD-MM-YYYY format as its the most commonly used date format across the globe. Further, I propose that we adopt YYYY-MM-DD in file names for sorting reasons. Given the mechanics of how filesystems and programming languages typically sort strings, this format ensures that files will be chronologically sortable.

Finding the best solution - Social Team Management

Evangelism Team Management in Social Media has been something @mikeal has been talking about since the first day I found the io.js community and started commenting.

I've done a lot of research into the topic, and have pretty much come out with just a few options. It seems that the only tools that can really get us what we need are either Buffer (https://bufferapp.com/app) or HootSuite (https://hootsuite.com/). We would need one of their team-based plans, with enough seats for the members of the WG that want access, plus leaders of the community.

We've discussed the topic on the Gitter, and several people, including myself, thought it would be reasonable to search for a sponsorship to get an account at either site that we can use to solve our problem. I'm not wise as to how sponsorships are normally granted, or who in the io.js leadership to talk to about this.

What are your thoughts on this? If you think it's a good idea, what is the best way to go about it? If you think it's not a good idea, would you share why? Of course it would probably be best to get @mikeal's sign off on whatever we do, as he's the one currently charged with handling the social accounts.

Social Media Style Guide

Would there be any interest in a social media style guide for io.js? This type of thing is employed at major companies to keep brand consistency across the board.

I know io.js isn't Google or Yahoo!, but I think it's important for us to come off as a unified front, and the only way to stay consistent enough to maintain that is to have a guide that anybody representing io.js can look to to know exactly how to write and respond appropriately.

I started working on a basic one when I first found iojs/website and saw the Evangelism issues, but haven't worked on it a ton since. I'd be happy to work on it some more and then post what I've got for everyone to take a look at.

If you do think this is a good idea, I'd really be interested in listening to your thoughts on how we should present io.js as a unified front.

High res logo for io.js Podcast

I'd like to start using the io.js logo on the podcast page (https://soundcloud.com/iojs). To do so, I'll need a very high res version of the dashavatar asset. Apple requires podcasts to provide a 1400x1400px to 3000x3000px JPG or PNG image for their cover art (source).

Assuming the size isn't prohibitively large, I'd lean towards the 3k version as it gives us a bit more future proofing for higher resolution displays. That would also give us the flexibility to downsample the image to 1.5k if necessary.

Evangelism WG Join Node Foundation?

Hey Everyone.

So as you all probably know, the io.js TC voted to join the Node.JS Foundation.

Meeting notes: nodejs/node#1700
Video: http://www.youtube.com/watch?v=UbYiFLf7MpU

As noted in nodejs/node#1705, all working groups will be moved to the new "nodejs" GitHub organization

The impact on Working Groups is that they will also be moved in to the "nodejs" org and become part of the Foundation. However, since the Working Groups are autonomous they have the ability to relocate and detach from the Foundation and that is their right. If there are concerns within your Working Group(s) about this move, please discuss it and come to a decision according to the governance procedures you have set up.

So: should the Evangelism Working Group join the Node.JS Foundation? Do we have any concerns, questions, etc?

Touch base: What do you think this WG should be, what should it produce, and what should it achieve?

The discussions in this WG have been a bit lop-sided in my eyes. I feel like everybody has their ideas of what this WG is, does, produces, achieves, etc. Everybody is looking writing against their vision or idea of the WG, but nobody has really defined outright what we're setting out to achieve in a measurable manner.

I'd like to know what everyone thinks about this--what are our exact goals? If you're willing, would you try to come up with a few, even if they don't come to you immediately? To help this, maybe think about what evangelism is in terms of software, and what it means to practice it.

Here are a few I have in mind:

  • Bring a strong social media presence that reflects positively on io.js.
  • Develop a unique writing style that anybody writing for io.js can use.
  • Through various media, bring in a noticeable amount of users to at least give io.js a shot.
  • Facilitate teaching of the actual piece of software called io.js, connecting community with experts in a way that works for those trying to learn.
  • Facilitate education about the principles behind io.js, and how its community is a part of that
  • Actively seek to involve other projects that wouldn't have supported, converted, or started without encouragement

Again, try to think of and respond with at least a few ideas of your own. If you have any responses to the ones I wrote, I'd really love to hear about those thoughts and talk about them.

Conference speaking opportunity (October 2015 US)

I am currently looking for a (keynote) speaker for a conference in October 2015 (US).
The talk should cover Node.js in general with some focus on enterprise use cases. The speaker should be member of one of the currently 'official' entities within Node.js/Io.js.

As there will be many representatives of high profile companies this is a great opportunity to establish Node.js in enterprise environments.

Call for Speakers

As the developers, writers, and speakers of io.js and Node.js have further developed the project, a demand for speakers has arisen.

It will be helpful to get a list of people willing to speak about the project in some form; this may be through presenting the roadmap slides, or by doing a keynote presentation for a conference. Regardless, we want to know if you're willing to speak about io.js or Node.js.

Please fill out the basic template below in order to allow for easy searching.

**Name:**
**Location:** (City, Region, and/or Country)
**Type of speaking:** (community and/or professional)
**Experience:** (Job Title and/or community roles)
**Contact:** (Email, Twitter, Facebook, or Website)

Example:
Name: Tierney Coren
Location: Albany, NY, USA
Type of speaking: Community
Experience: Community Contributor
Contact: Twitter

Original issue: nodejs/nodejs.org#110

Evangelism: Weekly Update Feb 27th

io.js 1.4.1 Release

Note: version 1.4.0 was tagged and built but not released. A libuv bug was discovered in the process so the release was aborted. We have jumped to 1.4.1 to avoid confusion.

Notable changes

  • process / promises: An'unhandledRejection' event is now emitted on process whenever a Promise is rejected and no error handler is attached to the Promise within a turn of the event loop. A 'rejectionHandled' event is now emitted whenever a Promise was rejected and an error handler was attached to it later than after an event loop turn. #758 (Petka Antonov)
  • streams: you can now use regular streams as an underlying socket for tls.connect() #926 (Fedor Indutny)
  • http: A new 'abort' event emitted when a http.ClientRequest is aborted by the client. #945 (Evan Lucas)
  • V8: Upgrade V8 to 4.1.0.21. Includes an embargoed fix, details should be available when embargo is lifted. A breaking ABI change has been held back from this upgrade, possibly to be included when io.js merges V8 4.2. See #952 for discussion.
  • npm: Upgrade npm to 2.6.0. Includes features to support the new registry and to prepare for npm@3. See npm CHANGELOG.md for details. Summary:
    • #5068 Add new logout command, and make it do something useful on both bearer-based and basic-based authed clients.
    • #6565 Warn that peerDependency behavior is changing and add a note to the docs.
    • #7171 Warn that engineStrict in package.json will be going away in the next major version of npm (coming soon!)
  • libuv: Upgrade to 1.4.2. See libuv ChangeLog for details of fixes.

ARM offers support for io.js on ARMv8

ARM contacted Rod Vagg, lead of the io.js Build Working Group, to offer their support to the io.js project. ARM and their hardware partners are on track to make ARMv8 a viable server platform and the nimble nature of server-side JavaScript make it a perfect fit to run on the new ARM.

Since ARMv8 is already being adopted by mobile device manufacturers, newer versions of V8 already have good support. Because of V8's pivotal role in Android, io.js is perfectly suited to track that support, and even contribute to it given our new relationships with the V8 team.

From the beginning of the io.js project, Rod has championed the role of ARM for io.js, for IoT, hobbyist, and server use. We already have ARMv6 builds of each release for devices such as Raspberry Pi. and ARMv7 builds for many more popular devices (including the Online Labs ARM-based cloud platform, who have also offered help to io.js). ARMv8 is the logical extension of this, but also has exciting potential for server-side applications, particularly given the new 64-bit support.

The build team is in the process of being given access to the Linaro ARMv8 Server Cluster for integration with the io.js CI platform, which should eventually lead to regular ARMv8 binary releases.

Community Updates

  • Reconciliation Proposal: The io.js project is preparing a plan for reconciliation that can be brought to The Node.js Foundation. Input from the community is very important at this early stage so please leave a comment.
  • New internal C++ Streams API: A fresh C++ Streams API landed in io.js this week, allowing you to wrap a TLS stream into another TLS stream.
  • io.js Roadmap: The Roadmap is the plan for the future of io.js. It presents the plans for the stability policy, and lists what the immediate priorities for io.js as a whole are.
  • Roadmap Slides Finished and Ready for Translation: The set of introductory slides for the Roadmap of io.js have been finished, and are ready for translation. Do you think you could present them to a group near you? Comment and we'll work with you to prepare you to present!
  • Microsoft io.js How-To for Azure Websites: Microsoft published a how-to tutorial for their Azure platform that describes how to use io.js with Azure Websites.
  • Floobits moves to io.js: The code pairing software Floobits converted their platform to io.js, in part because of frustration with Node's slower release cycle, because the inclusion of more ES6 features without the need for the --harmony flag, and because they felt changes from 0.10.0 to 0.12.0 weren't very big.
  • Anand Mani Sankar's Node.js vs io.js: Why the fork?!?: Anand wrote a good, for the most part objective, post about the recent history of io.js, and what we hope to achieve with it. A good read for people who aren't engaged in the community to catch up with.
  • iojs-jp - New io.js Japanese Blog: The iojs-jp community has created a localized io.js related blog to disseminate content in their language. If you're interested, take a look!
  • iojs-cn - New io.js Chinese Blog: Similarly to the iojs-jp community, the iojs-cn community created a localized blog to publish posts about io.js to in their language. Make sure to visit if you're curious about iojs-cn or Chinese news about io.js!
  • Roadmap Slides Review - A review of the roadmap slides before they were released to ensure they met with the message the project upholds.

io.js Support Added

# io.js 1.4.1 Release

_Note: version **1.4.0** was tagged and built but not released. A libuv bug was discovered in the process so the release was aborted. We have jumped to 1.4.1 to avoid confusion._

## Notable changes

* **process** / **promises**: An`'unhandledRejection'` event is now emitted on `process` whenever a `Promise` is rejected and no error handler is attached to the `Promise` within a turn of the event loop. A `'rejectionHandled'` event is now emitted whenever a `Promise` was rejected and an error handler was attached to it later than after an event loop turn.  [#758](https://github.com/iojs/io.js/pull/758) (Petka Antonov)
* **streams**: you can now use regular streams as an underlying socket for `tls.connect()` [#926](https://github.com/iojs/io.js/pull/926) (Fedor Indutny)
* **http**: A new `'abort'` event emitted when a `http.ClientRequest` is aborted by the client. [#945](https://github.com/iojs/io.js/pull/945) (Evan Lucas)
* **V8**: Upgrade V8 to 4.1.0.21. Includes an embargoed fix, details should be available when embargo is lifted. A breaking ABI change has been held back from this upgrade, possibly to be included when io.js merges V8 4.2. See [#952](https://github.com/iojs/io.js/pull/952) for discussion.
* **npm**: Upgrade npm to 2.6.0. Includes features to support the new registry and to prepare for `npm@3`. See [npm CHANGELOG.md](https://github.com/npm/npm/blob/master/CHANGELOG.md#v260-2015-02-12) for details. Summary:
  * [#5068](https://github.com/npm/npm/issues/5068) Add new logout command, and make it do something useful on both bearer-based and basic-based authed clients.
  * [#6565](https://github.com/npm/npm/issues/6565) Warn that `peerDependency` behavior is changing and add a note to the docs.
  * [#7171](https://github.com/npm/npm/issues/7171) Warn that `engineStrict` in `package.json` will be going away in the next major version of npm (coming soon!)
* **libuv**: Upgrade to 1.4.2. See [libuv ChangeLog](https://github.com/libuv/libuv/blob/v1.x/ChangeLog) for details of fixes.

# ARM offers support for io.js on ARMv8

ARM contacted Rod Vagg, lead of the io.js Build Working Group, to offer their support to the io.js project. ARM and their hardware partners are on track to make ARMv8 a viable server platform and the nimble nature of server-side JavaScript make it a perfect fit to run on the new ARM.

Since ARMv8 is already being adopted by mobile device manufacturers, newer versions of V8 already have good support. Because of V8's pivotal role in Android, io.js is perfectly suited to track that support, and even contribute to it given our new relationships with the V8 team.

From the beginning of the io.js project, Rod has championed the role of ARM for io.js, for IoT, hobbyist, and server use. We already have ARMv6 builds of each release for devices such as Raspberry Pi. and ARMv7 builds for many more popular devices (including the Online Labs ARM-based cloud platform, who have also offered help to io.js). ARMv8 is the logical extension of this, but also has exciting potential for server-side applications, particularly given the new 64-bit support.

The build team is in the process of being given access to the Linaro ARMv8 Server Cluster for integration with the io.js CI platform, which should eventually lead to regular ARMv8 binary releases.

# Community Updates

* [**Reconciliation Proposal**](https://github.com/iojs/io.js/issues/978): The io.js project is preparing a plan for reconciliation that can be brought to The Node.js Foundation. Input from the community is very important at this early stage so please leave a comment. 
* **New internal C++ Streams API**: A [fresh C++ Streams API](https://github.com/iojs/io.js/commit/b9686233fc0be679d7ba1262b611711629ee334e) landed in io.js this week, allowing you to wrap a TLS stream into another TLS stream. 
* **io.js Roadmap**: [The Roadmap](https://github.com/iojs/io.js/blob/v1.x/ROADMAP.md) is the plan for the future of io.js. It presents the plans for the stability policy, and lists what the immediate priorities for io.js as a whole are.
* **Roadmap Slides Finished and Ready for Translation**: The set of introductory slides for the Roadmap of io.js [have been finished, and are ready for translation](https://github.com/iojs/roadmap/issues/18). Do you think you could present them to a group near you? Comment and we'll work with you to prepare you to present! 
* **Microsoft io.js How-To for Azure Websites**: Microsoft [published a how-to](http://azure.microsoft.com/en-us/documentation/articles/web-sites-nodejs-iojs/) tutorial for their Azure platform that describes how to use io.js with Azure Websites.
* **Floobits moves to io.js**: The code pairing software Floobits [converted their platform to io.js](https://news.floobits.com/2015/02/23/on-moving-to-io.js/), in part because of frustration with Node's slower release cycle, because the inclusion of more ES6 features without the need for the `--harmony` flag, and because they felt changes from 0.10.0 to 0.12.0 weren't very big.
* **Anand Mani Sankar's _Node.js vs io.js: Why the fork?!?_**: Anand wrote a good, for the most part objective, [post about the recent history of io.js](http://anandmanisankar.com/posts/nodejs-iojs-why-the-fork/#.VO82hE60PVw.twitter), and what we hope to achieve with it. A good read for people who aren't engaged in the community to catch up with.
* **iojs-jp - New io.js Japanese Blog**: The iojs-jp community has created a [localized io.js related blog](http://blog.iojs.jp/) to disseminate content in their language. If you're interested, take a look!
* **iojs-cn - New io.js Chinese Blog**: Similarly to the iojs-jp community, the iojs-cn community created a [localized blog](http://cn.iojs.org/) to publish posts about io.js to in their language. Make sure to visit if you're curious about iojs-cn or Chinese news about io.js!
* **[Roadmap Slides Review](https://www.youtube.com/watch?v=etI_UD4wXlo)** - A review of the roadmap slides before they were released to ensure they met with the message the project upholds.

# io.js Support Added
* **[Wallby.js](http://wallabyjs.com/)**, a while-you-write testing library for JavaScript, hit version 1.0 and [added support for io.js](http://dm.gl/2015/02/23/wallaby-version-one/)!
* **[jsdom](https://github.com/tmpvar/jsdom)**, an implementation of the WHATWG DOM and HTML standards, just hit [version 4.0.0](https://github.com/tmpvar/jsdom/blob/master/Changelog.md#400), which added a _requirement_ of io.js.
* **[give](https://github.com/mmalecki/give)**'s creator [tweeted](https://twitter.com/maciejmalecki/status/569629100215816192) that newer versions of give support io.js. Give is a git-based node.js/io.js version manager.
* The **Firebase Realtime Client**, the official web/node.js JavaScript client for Firebase, [tweeted](https://twitter.com/FirebaseRelease/status/570000737343647744) that they added support for io.js in [version 2.2.1](https://www.firebase.com/docs/web/changelog.html#section-realtime-client)
* **Semaphore**, a hosted continuous integrations service, [tweeted](https://twitter.com/semaphoreapp/status/570987355005431809) about added io.js support in their [Platform update on February 24th, 2015](https://semaphoreapp.com/blog/2015/02/17/platform-update-on-february-24th.html?utm_source=twitter&utm_medium=social&utm_content=platform_update_launch&utm_campaign=platformupdate). 

Update Readme with initial member list

Its awesome so many people want to get involved. One comment: the working_groups.md document references the evanglism readme which has a list of the members. Once we've come to a consensus on our initial group we should update our README.md accordingly.

Inside io.js podcast season 1

Let's do a podcast about io.js :)

Rather than just a round table or raw interviews we should edit a bunch of things together around specific topics.

First, let's build a list of show topics and then use that to build out an initial interview list.

Show Ideas:

  • Why io.js? (Why was the project created, why did we fork)
  • The TC and open governance, consensus seeking, etc.
  • The i18n community, creation and current workflows
  • The roadmap
  • What is libuv
  • trace_event
  • AsyncWrap
  • Streams WG

List of Plugs

We should create a simple list of plugs that can be read out at the end of each TC/WG meeting.

Meeting hosts often wrap up the meeting with some basics on where we're active and how to get in contact. Unfortunately, it seems hosts aren't 100% clear what channels they should be directing people to.

iojs/io.js repo traffic insight

Previously we've seen traffic spikes on the io.js core repo every friday, presumably due to the weekly updates. This week, however, traffic was normal on friday.

@mikeal has speculated this may be due to the weekly update being posted much later than it had been before.

Note: I have been keeping eyes on this for longer than the 2 weeks or so the chart shows.

Traffic graph (visible to collaborators only 😞) https://github.com/iojs/io.js/graphs/traffic

Full pics for anyone without access:

screen shot 2015-03-09 at 4 53 31 pm
screen shot 2015-03-09 at 4 53 45 pm

See also: https://twitter.com/Fishrock123/status/575034708683137024

New Slide Deck about The Node Foundation

We've been getting a lot of questions about The Node Foundation and the merger, it would be good to put together a web based slide deck like we did for the roadmap.

I'm giving a talk at ONE-SHOT Oslo where we're getting people on twitter and from the conference to send in questions before the talk, picking 10, and then spending my time answering all of them. I could write this up as a generic deck if we find some HTML slide software that allows me to write up extensive notes for the whole answer.

It would be great if after that people translated it and did a few talks at local non-english meetups as well.

Website and Branding Progress

@vjk2005 Can we get an update on the website and branding progress? The website design and the need to move forward was discussed at the @iojs/website (pinging them to join this discussion) WG meeting yesterday. We need to pick a clear path, and start moving forward.

Some questions:

  • How is the site progressing?
  • What should we to do from here? Should we continue with you solo, with help, or in another way?

I don't mean to place stress on you, @vjk2005, but things are moving quickly and we want to keep up. We're happy to do whatever is needed to help get the site going as soon as possible.

Revive Node Forward repos and maintain them.

I found the Node Forward GitHub recently, and I really, really love the repos and the ideas they represent. I think they could be a good starting point for io.js to start building a community outside of the contributors. Whether they stay in Node forward, or move to iojs is up for discussion. Here are some of my thoughts:

io.js has the most engaged and friendly community I've encountered in OSS behind it. If we can get the experienced community to lend a hand in teaching those new to io.js, helping those that are stuck with a problem, and provide a common area for people to collaborate and succeed, it would be so much easier to break into io.js.

The barrier to entry is extremely high for Node. The NodeForward repos are a great opportunity to lower that barrier dramatically for io.js, which would allow us to pick up even more momentum and adoption behind/of the project.

The problem of starting with Node is something I am extremely familiar with. I'm not the typical programmer, as I haven't progressed from a moderately early position in a long time. I've really struggled with trying to communicate with others and understand what I need to do to really program. I have tried every option I could find on the Internet to try to solve this. There's been a little relief in the past couple weeks, but the types of things in the NodeForward repo are the exact things I needed when I was starting, and still need to an extent, to really be able to become serious about it all.

The reason I'm pushing hard for this is that I'd like to make this option available for others in the future, so they don't have to struggle as much as I have. I have a solid appreciation for the difficulty of learning to program, and I think the NodeForward repos are a way to ultimately negate a lot of that difficulty for people who started from nothing, like me.

I begun writing this issue by listing the different repos, but kept moving my writing toward more general terms. I did that because they're all about the same thing--helping the community--but are slight variations that help different kinds of people. This is the bottom line, for me. We can help support the io.js community in a way that Node 100% lacked. I think this should be something that is kept active as a way to engage the community and help teach, maintain, and adopt the software we're evangelizing.

Social Accounts and Social Ideas

I've grabbed a few accounts on relevant sites, and I thought it would be good for us to coordinate our accounts and to share ideas of what we could do with them. Please share if you've grabbed an account for iojs on any relevant sites, so we can discuss their future.

Sites I've grabbed:

  • Hacker News: Automating this to post articles from the official io.js Medium account might be smart. Officially responding to questions about io.js in io.js-related articles would also be a good idea.
  • EchoJS: I think the ideas I had for HN are relevant for this account too. EchoJS has shown enormous support for io.js, and it's definitely worth being active and contributing back.
  • Twitch: Programming streams and talk show-style streams have become more popular and supported on Twitch lately. It's definitely a good community to get involved with, as it's established and successful. Ideas for things we could stream would be excellent. I was thinking core contributors could stream working on core. Maybe TC members could stream something? Not 100% sure about everything they do.

messaging – io.js is much more than just es6.

tl;dr; rather than riding on the laurels of es6 support in v8, I'd like to see io.js find a way to tactfully communicate that io.js is a good, safe bet for business and definitely not "hot, new unstable tech".

This is probably obvious but in my quick skimming of the issue queue I didn't see any discussion about it.

image

"Bringing es6 to node" isn't doing io.js enough justice. io.js is doing so much more than just getting a few new JavaScript features, in-fact the efforts going into io.js is everything except the es6 features – that was just a nice side-effect of updating v8, and now it's being used as the primary messaging?

"unstable" & "experimental"

A significant perception problem io.js has at the moment is that it's seen as the "unstable", "experimental" version of node. es6 itself is still seen as "unstable" and "experimental" since the spec has been in flux and support in various engines a bit rocky. Focusing on the es6 support rather than all the other awesome shit might be compounding the perception problem.

"If it ain't broke, don't fix it."

Rapid iteration is important so bugs are squashed quickly and additional features be laid, but the the more conservative is more likely to focus on the corollary: more opportunities to introduce bugs and more APIs changing requiring rewrites to working code. Would be good to flip this around and make it clear that this should mean that there are less bugs, not more.

One of the first benefits i see communicated is "chrome doesn't even support that version of v8". This doesn't mean anything to most developers as it's hard to imagine what the downsides are of an unsupported v8. An embargoed security update would be a gold medal for concrete examples to demonstrate this. GOLD MEDAL.

Also might be good to clear up how this fits in the idea that one day node would be "done".

trickle down effects

I realise that the messaging is politically sensitive, and perhaps this is the best of a bad bunch. It's clear though that es6 was/is probably the quickest way to get developers excited about io.js – people don't generally get as piqued up about escaping a corporate ************ and implementing new governance models as they do about "exciting new ways to define a string". es6 may not a continue to be a good differentiator though – given that people see io.js as the new unstable branch of node, as it's conceivable that many are over-confident that the es6 features will eventually trickle downstream into node.

I'd like to suggest focusing on more "objective", quantitative metrics like user engagement, number of bugs fixed, number of downloads, benchmarks, state of the CI suite, etc.

Sadly I don't have any concrete suggestions for a new tagline.

Evangelism: Weekly Update March 20th

io.js 1.6 release

This week we had a two io.js releases v1.6.1 and v1.6.0, complete changelog can be found on GitHub.

Notable changes

1.6.1

  • path: New type-checking on path.resolve() #1153 uncovered some edge-cases being relied upon in the wild, most notably path.dirname(undefined). Type-checking has been loosened for path.dirname(), path.basename(), and path.extname() (Colin Ihrig) #1216.
  • querystring: Internal optimizations in querystring.parse() and querystring.stringify() #847 prevented Number literals from being properly converted via querystring.escape() #1208, exposing a blind-spot in the test suite. The bug and the tests have now been fixed (Jeremiah Senkpiel) #1213.

1.6.0

  • node: a new -r or --require command-line option can be used to pre-load modules at start-up (Ali Ijaz Sheikh) #881.
  • querystring: parse() and stringify() are now faster (Brian White) #847.
  • http: the http.ClientRequest#flush() method has been deprecated and replaced with http.ClientRequest#flushHeaders() to match the same change now in Node.js v0.12 as per joyent/node#9048 (Yosuke Furukawa) #1156.
  • net: allow server.listen() to accept a String option for port, e.g. { port: "1234" }, to match the same option being accepted in net.connect() as of joyent/node#9268 (Ben Noordhuis) #1116.
  • tls: further work on the reported memory leak although there appears to be a minor leak remaining for the use-case in question, track progress at #1075.
  • v8: backport a fix for an integer overflow when --max_old_space_size values above 4096 are used (Ben Noordhuis) #1166.
  • platforms: the io.js CI system now reports passes on FreeBSD and SmartOS (Solaris).
  • npm: upgrade npm to 2.7.1. See npm CHANGELOG.md for details. Summary:
    • 6823807 #7121 npm install --save for Git dependencies saves the URL passed in, instead of the temporary directory used to clone the remote repo. Fixes using Git dependencies when shrinkwwapping. In the process, rewrote the Git dependency caching code. Again. No more single-letter variable names, and a much clearer workflow. (@othiym23)
    • abdd040 [email protected]: Provide more helpful error messages when JSON parse errors are encountered by using a more forgiving JSON parser than JSON.parse. (@smikes)
    • c56cfcd #7525 npm dedupe handles scoped packages. (@KidkArolis)
    • 4ef1412 #7075 If you try to tag a release as a valid semver range, npm publish and npm tag will error early instead of proceeding. (@smikes)

Known Issues

  • Possible remaining TLS-related memory leak(s), details at #1075.
  • Surrogate pair in REPL can freeze terminal #690
  • Not possible to build io.js as a static library #686
  • process.send() is not synchronous as the docs suggest, a regression introduced in 1.0.2, see #760 and fix in #774
  • Calling dns.setServers() while a DNS query is in progress can cause the process to crash on a failed assertion #894

Community Updates

  • browserify supports io.js, you can check the announcement here
  • express.js added support to io.js
  • Over the last two weeks we got access to hardware from Joyent and upstreamed a patch to V8 so we got io.js building. After that we worked on passing tests for both SmartOS and FreeBSD which as of two days ago now pass, this was thanks to the amazing work of the build team and Johan Bergström
  • Petka Antonov is proposing a workers implementation in io.js under an experimental flag, you can join the discussion here
  • io.js upgraded openssl to 1.0.1m

Upcoming Events

  • NodeConf tickets are on sale, June 8th and 9th at Oakland, CA and NodeConf Adventure for June 11th - 14th at Walker Creek Ranch, CA
  • CascadiaJS tickets are on sale, July 8th - 10th at Washington State
  • NodeConf EU tickets are on sale, September 6th - 9th at Waterford, Ireland

overly liberal artistic license with the pokéball design

Not sure how this happened but the official io.js pokéball might have employed a bit too much artistic license with its pokéball design:

image

Firstly I'd like to state I enjoy the adaption of the hexagonal shape to the pokéball, nice work, however – while this is instantly recognisable as a pokéball, I believe the overall design deviates a little too far from the canonical pokéball design, such that it very nearly looks as though it could be something else entirely, something from Digimon perhaps. We're in Pokéball uncanny valley country.

The most glaring problem with the design is that the white circle and the horizontal black line should be horizontally & vertically centered, rather than in their current positions towards the top and bottom of the pokéball. Also, it might seem like pedantry but a black line separating fields of red & white is one of the most recognizable pokéball aspects of all time – deferral to the non-standard off-white/cream in the bottom half of the io.js pokéball spoils the signature style. And look, I'm honestly not sure what's going on with that additional horizontal line at the top there – is that supposed to be the pokéball's mouth? I don't think pokéballs even have mouths. Maybe it's a pocket. A coin slot? I'm not sure, but it doesn't belong.

Top points for creativity and interpretation but overall it's a little too artsy and looks more like a knockoff pokéball that someone might sell from under his coat at the beach and I don't think that accurately reflects io.js values.

image

Worksgroups under Node foundation

In advance of the formation of the Node foundation, we'd like to start working groups using the policies outlined in dev-policy https://github.com/jasnell/dev-policy.

The current list is:

https://github.com/mhdawson/workgroup-proposals

We already have a number of interested parties and plan to get started in the next week or so.

We wanted to publicize within the io.js community to find additional people that would be interested and it was suggested in a recent call that the best way to do this would be to open an issue on this project.

If there are people who are interested they can either submit a pull request/open an issue on https://github.com/mhdawson/workgroup-proposals or let me know their contact details by emailing me at [email protected]

Evangelism: Weekly Update Mar 6th

io.js 1.5.0 Release

On Friday, March 6th, @rvagg released io.js v1.5.0. The complete change log can be found on GitHub.

Notable changes

  • buffer: New Buffer#indexOf() method, modelled off Array#indexOf(). Accepts a String, Buffer or a Number. Strings are interpreted as UTF8. (Trevor Norris) #561
  • fs: options object properties in 'fs' methods no longer perform a hasOwnProperty() check, thereby allowing options objects to have prototype properties that apply. (Jonathan Ong) #635
  • tls: A likely TLS memory leak was reported by PayPal. Some of the recent changes in stream_wrap appear to be to blame. The initial fix is in #1078, you can track the progress toward closing the leak at #1075 (Fedor Indutny).
  • npm: Upgrade npm to 2.7.0. See npm CHANGELOG.md for details including why this is a semver-minor when it could have been semver-major. Summary:
    • 145af65
      #4887 Replace calls to the
      node-gyp script bundled with npm by passing the
      --node-gyp=/path/to/node-gyp option to npm. Swap in pangyp or a version
      of node-gyp modified to work better with io.js without having to touch
      npm's code! (@ackalker)
    • 2f6a1df
      #1999 Only run stop and start
      scripts (plus their pre- and post- scripts) when there's no restart script
      defined. This makes it easier to support graceful restarts of services
      managed by npm. (@watilde /
      @scien)
    • 448efd0
      #2853 Add support for --dev and
      --prod to npm ls, so that you can list only the trees of production or
      development dependencies, as desired.
      (@watilde)
    • a0a8777
      #7463 Split the list printed by
      npm run-script into lifecycle scripts and scripts directly invoked via npm run-script. (@watilde)
    • a5edc17
      #6749 [email protected]:
      Support for passing scopes to npm init so packages are initialized as part
      of that scope / organization / team. (@watilde)
  • TC: Colin Ihrig (@cjihrig) resigned from the TC due to his desire to do more code and fewer meetings.

Known issues

  • Possible TLS-related memory leak, details at #1075.
  • Windows still reports some minor test failures and we are continuing to address all of these as a priority. See #1005.
  • Surrogate pair in REPL can freeze terminal #690
  • Not possible to build io.js as a static library #686
  • process.send() is not synchronous as the docs suggest, a regression introduced in 1.0.2, see #760 and fix in #774

Community Updates

  • You can relax knowing that io.js and latest node.js [are not affected]((https://strongloop.com/strongblog/are-node-and-io-js-affected-by-the-freak-attack-openssl-vulnerability/) by the FREAK Attack. You are running io.js or the latest version of node.js, right?
  • Walmart is now sponsoring a build machine for the io.js Jenkins CI system. The @iojs/build team is working on creating io.js SunOS binaries (like you can get from nodejs.org). A V8 fix (iojs/io.js#1079) needs to be landed first before more progress can be made.
  • We would also like to thank the following companies for contributing hardware and related technology/support/engineering for io.js builds:
    • Digital Ocean (mainly Linux)
    • Rackspace (mainly Windows)
    • Voxer (OS X and FreeBSD)
    • NodeSource (ARMv6 & ARMv7)
    • Linaro (ARMv8)
    • Walmart (SmartOS / Solaris)
  • The io.js community has been hard at work on the internationalization of all of its content. There are now over 20 active languages published on iojs.org and i18n community sites. Additionally, i18n links (iojs/website#258) have been added to the website footer for easy access. Are we missing your language? Help us add it!
  • Speaking of translations, the io.js roadmap presentation has been updated to link to other language versions.
  • It seems that PayPal is running an experiment comparing Kappa on io.js vs node.js 0.12 vs node.js v0.10. The PayPal team identified a likely TLS memory leak. Initial fix is in #1078 and progress towards closing is in #1075
  • NodeSource is now providing io.js Linux binary packages for Ubuntu/Debian as well as RHEL/Fedora distributions.
  • The io.js [Docker build]((https://registry.hub.docker.com/u/library/iojs/) is one of thirteen new official Docker repositories added in January and February.
  • NodeBots and IoT people should be happy to hear that the just-announced Tessel2 runs io.js natively.
  • @maxbeatty is working on a new version of the jsperf.com backend, running on io.js and it is entirely open source. Contributions are welcome!
  • @eranhammer wrote a blog post called The Node Version Dilemma which discusses the various node.js / io.js versions and proposes which ones to use and when to use them.

io.js Support Added

Add member to Evangelism WG

I'd like to propose that @SVincent be added as a member to the Evangelism WG. He's contributed high-quality work and discussion, and is motivated to continue working under the WG.

He asked me if I could review the contents of #6 in a bit more detail than we could over text on GitHub. I accepted, and we spent 3 hours going over, arranging and re-arranging.

The document ended up more solid than I could have hoped for, and we came up with some excellent ideas for it and other issues to propose to the WG (which I'm going write up and post ASAP) while we were working. He contributed a ton of really good ideas and had a ton of well thought-out input. The WG would definitely benefit from having him as a member.

Making Contributing to the Evangelism WG Accessible and Easy

Apparently people want to contribute to the Evangelism WG, and don't know how. What can we do to make this obvious and easy? If you have any ideas, please share them. Also if you're trying to find a way to contribute, participate in this conversation! We want to hear from you, and help you get involved immediately.

Right now, we don't have a lot of outlets for people to create content for. What are some ideas for this? Official channels and community channels are both possibilities. We need to come up with several ways for people to help out.

Just a few ideas I have:

  • Document creation: Create issues/PRs for documents that we can use to help the community
  • Document addition: There are several additions to the Social Media Style Guide I'd like to make, but haven't had time for. I'm going to create an issue for this, so someone can help work on that.
  • Community Blog Posts: Community posts to the blog, highlighting specific aspects of the community, tools, companies, etc.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.