Contribute to Ember.js 2.0. No coding required.

Wow! This takes me back! Please check the date this post was authored, as it may no longer be relevant in a modern context.

Ember’s path to a 2.0 release has been announced in an RFC. Our ambition is not simply to have 2.0 be a great framework, but for every 1.x codebase to make the transition forward with us.

There is a lot of code to be written. Contributing code to Ember.js, especially if you are new to open source development, is a rewarding and skills-building experience. The project maintains a high bar for technical contribution, and fixing a bug often involves a healthy dose of new knowledge. Additionally, there is a mature process for adding new features and bug fixes that should serve as an inspiration to your development process elsewhere.

If you have the time and will, adding code to Ember.js is an opportunity to collaborate with wonderful and extremely smart people.

“the time” is what keeps most developers from contributing to open source. There are businesses to build, families to raise, and always another Tolkien movie coming out.

But you don’t need to contribute code to help Ember.js reach its 2.0 goals. Here are five great ways to be a part of the process.

Test your app on beta releases

When opening a Github issue for a bug, it is important to note which channel of Ember.js the bug is in:

  • “canary” is the master branch of Ember.js. Every six weeks it forks to create the new Beta.
  • “beta” builds are released every week for six weeks, then graduate to release.
  • “release” builds are released every six weeks.

This cycle means that every six weeks, a release candidate of Ember.js is forked. Between the first beta release and the graduation of that release to release, we need feedback from real-world applications to discover bugs. We think of this process as a train. Beta forks, bug fixes land, and after six weeks that branch is release worthy.

While code is in beta, much of the coding community’s focus is there. If a bug is undiscovered in beta and graduates into release, fixing it takes time away from the new beta and canary branches. Bugs in release, and in point releases (like 1.7.1 or 1.8.1), make the train jerk around.

Testing your application with beta builds ensures quality releases on a steady schedule. Once or twice every six weeks, update to beta and report bad behavior on Github. With Ember-CLI this is as easy as:

bower install --save ember#beta

Or install a specific version:

bower install --save ember#1.9.0-beta.1

As part of installation you may be prompted by Bower to manually pick a specific version of Ember. After installation, you may need to restart your server. Like any change to bower dependencies, stay a little suspicious. Deleting the bower_components/ folder and doing a fresh bower install may be warranted.

You can also download builds from the website. Even ten minutes of beta review every six weeks is incredibly helpful. You don’t need to ship beta builds to production to generate meaningful feedback.

Catch and update old patterns in the documentation

As Ember.js 2.0 comes closer, more documentation at emberjs.com will be updated to match Ember-CLI’s conventions. Documentation has gone from a sore spot to a point of pride with Ember, but it is impossible for any single person to ensure all guides and API docs are up to date.

If you see something, PR something. The source of Ember’s guides (and the rest of the website) is on github. The API documentation is part of Ember’s own code. Making and previewing changes to the website is easy. Click the fork button, then start the preview server:

git clone git@github.com:my-github-account/website.git
cd website/
bundle
bundle exec middleman

And you’re off! PRs for something as small as a grammar or spelling correction are welcome, but most valuable is catching old or non-idiomatic recommendations and updating them.

Talk about your own solutions

Each user of Ember solves unique challenges. Sharing your solution to an interesting problem is a valuable way to contribute to our community, be it through a blog post, meetup talk, or video. Getting your business or personal name out there is a bonus!

When writing about a topic for the first time, consider sharing your content on IRC or elsewhere for feedback. I’m always happy to review a post myself!

If you write or otherwise share something, make sure it gets out there for other developers to see. Consider submitting it to one of these Ember resources:

  • Ember Weekly is the oldest Ember.js newsletter, and reaches many developers.
  • Ember Watch maintains a Twitter account and webpage with many resources.

Or to any general JavaScript resource.

If you don’t have a place to publish, you can always consider posting at Ember’s active discourse forum.

Help others

Discourse, StackOverflow, and the IRC chatrooms are where new developers go to ask questions. Walking someone though an new concept, or triaging what might be a bug is a good way to welcome new users to the community. Getting bugs to Github and clarifying concepts is incredibly helpful, and gives new users a great introduction.

The community hangs in three chatrooms on IRC:

  • #emberjs is for general guidance, and it linked to from the Ember webpage.
  • #emberjs-dev is for internals discussion and more advanced topics.
  • #ember-cli is where contributors and maintainers of ember-cli tend to hang.

Share your thoughts on RFCs

Last but not least, and not for the rushed or faint of heart, is to review and comment on RFCs. Ember RFCs are documents prepared by the community and core team for discussion and feedback.

Feedback on an RFC should be specific, ideally taking into account your experiences with the problem addressed by the RFC. It should be researched and considered. We hope that discussion on RFCs moves a proposal forward until it is evident that it should be rejected or implemented, so “+1” comments should be avoided.

Understanding the issues raised by an RFC can be challenging and may not be a quick task, but it is important discussion that shapes the future of the framework.

I’m excited to do my part in making Ember’s 2.0 goals a reality. See you at EmberConf to celebrate!

Want to ensure your team is ready for 2.0? Or sponsor development to land features sooner? My consulting business 201 Created is looking for new projects this January!