Getting started contributing to open source isn't always easy. Usually, there's a whole new code base we need to understand before starting contributing. Sometimes it's well-documented, sometimes not. That's why I always recommend people to begin with documentation first and code later. It's a perfect way to get started contributing without any specialized tooling or knowledge, and usually, open source projects always welcome updates to the documentation.
I've decided to create a guide on how to contribute to the Ember ecosystem starting with contributions that don't even require coding and ending up with something a bit more advanced. This is part two.
If you haven't read part one on The Ember Times, then I recommend reading that first.
Every six weeks there are new releases of Ember.js, Ember CLI and Ember Data. All the new features, bug fixes, and deprecations need to be collected in the release post.
For contributing to the release post you don't need any specialized knowledge about Ember or any special technical skills. This is a great way to get started contributing to the Ember ecosystem.
First of all, you are not expected to write the entire blog post yourself. Ideally, you write a small section of it which is extremely helpful. To write a section you need to know what to write about. Currently there's no easy way to get an overview of what needs to go into every release post (this is something I'm currently trying to fix).
So, for now, the way to get started is to let us know in the
#dev-ember-learning channel on Discord that you want to help out.
There are a couple of different categories you could write about for a release post:
Features are new things introduced in a specific version. A good example of this is angle bracket component invocation syntax that allows developers to invoke a component like this:
<XButton @color="Blue"/> instead of `
Usually, the information needed to write about a feature is described in a related RFC.
This is for the introduction of deprecation warnings for features that are going to be removed in a later version. A good example of this is the deprecation of
sendAction. You don't need to know the deprecations beforehand since they are always described in the deprecations app which is where you should reference whatever you write in the release post.
Once you found a topic and started writing you're probably ready for some early feedback. You can either send whoever suggested a topic for you a preview of what you've written or if you're feeling particularly adventurous, create a pull request right away.
The pull request has to be made against the
ember-learn repository just like in the previous post. It is important that the pull request is made towards the work-in-progress branch of the upcoming release post. Ask whoever suggested your topic about that branch.
Once you've made the pull request please post the link to it in
dev-ember-learning so someone can review it promptly.
Thank you! Your help is truly appreciated.
Feel ready to get started?
- Contact someone in
dev-ember-learningand get a topic
- Start writing
- Get early feedback
- Submit a pull request
Stay tuned for the next post.