How to contribute to WordPress Calypso

In this article, we will look at how to contribute to WordPress Calypso (let’s call it Calypso) by solving an Issue. It is good to mention, that you can contribute also by reporting an Issue, writing the documentation or suggesting an enhancement. Here are a few steps which we will follow in the process of contributing. I’m going to explain what is Calypso, how to select a suitable task (Issue), reproduce it, keep the rules or contributing, make a PR (pull request) and discuss the solution with other participants.

What is Calypso?

js-apis-future WordPress Calypso

https://wp-cron.com/2015/11/29/javascript-apis-and-the-future-of-wordpress-scott-bolinger/

“Calypso is the new WordPress.com front-end – a beautiful redesign of the WordPress dashboard using a single-page web application, powered by the WordPress.com REST API. Calypso is built for reading, writing, and managing all of your WordPress sites in one place.”- Calypso GitHub page

Choose an appropriate task

Calypso’s GitHub page lists many Issues. You can work on any of them, however, I recommend to work on those with the label [Type] Good First Change as Calypso developers put this label on Issues suitable for newcomers. Make sure, it’s an Issue you can actually work on — some of them require knowledge and presence of Automattic’s (the company behind Calypso) internal tools.

Labels

The label [Type] Good First Change informs, that for solving such Issue, you mostly don’t need to have the access to the internal Automattic’s tools and probably is easy to solve. Such Issues with this label have mostly low priority, which can be obvious also thanks to the [Pri] Low label.

The Issue may have also other labels. They can inform about the part of Calypso where was the issue discovered (for instance: Plans, Editor, Posts, devDocs, i18n), whether it is a bug, an enhancement or a task. Pull Requests (PRs) which are ready for review are usually labeled with [Status] Needs Review or [Status] Needs Design Review. Those PRs which are in progress are labeled with [Status] In Progress. If you need a reply from the author of the Issue, label it with [Status] Needs Author Reply. Finally, if the PR is ready to merge, Automatticians label it with [Status] Ready to Merge.
I stress, that only contributors with write access to Calypso’s Github repository (usually Automatticians) can add an appropriate label. If you don’t have the access, the matticbot adds the OSS Citizen label.

Reproduce the Issue

If you are a newcomer or outside of Automattic, don’t forget to fork Calypso on GitHub. You will work on your own copy of Calypso. Also, create your own branch on the fork. Notice, how Automattician’s create their branches. Usually, it looks like add/... , fix/..., remove/... or  update/... Try naming your branch according to what you are going to do. Keep your fork always up-to-date with the master branch of the original repository. As for keeping it up-to-date tutorial, I recommend rebasing your fork and branch instead of merging new commits from Calypso developers.

Now find the subpage, component or the place in the code, which was mentioned in your selected Issue. Keep the developer tools like console or React Developer Tools always open. As for React Developer Tools, notice that they are available only in Chrome and Firefox browsers. Next, it is good to mention, that proper code editor can help you a lot at this moment. I recommend using PhpStorm from JetBrains. This editor can remember the project’s history, changes, has many useful shortcuts for searching in files and other things. When you find the wanted piece of code, make sure, the bug is still in here and wasn’t fixed yet. Now let’s think about some solution.

Rules of contributing

Every project has its own rules or contributing. Before you write some code, you should read and keep the  Calypso’s Contributor Code of Conduct, coding guidelines and contributing.md. Don’t forget to spaces, indentation, whitespaces, redundant blank lines and other things, which can PhpStorm really help you with. Test every use case in every possible browser if needed. Be careful about rewriting or deleting the original code because the components can be used in many other places. Use mostly ES6 syntax. If you are not sure about something, write a comment to that Issue on Github and ask.

Commits

Make your commits small and try writing meaningful commit messages. Learn how to rebase interactively. Because you will certainly need it.

Pull request + Discussion

Now, when your solution is ready, make a PR from a fork. Don’t forget to write a meaningful message to your PR. Finally, other participants will review your code and you will discuss it. Don’t worry, nobody will be nasty because everybody keeps the Code of Conduct. Just prepare yourself for some good advice and tips from more experienced people, who are trying to keep some coding standards in their project.

If you are not sure about something, notice, how Automatticians do that or just ask somebody. Let me show you my own example.