Hi! Thank you for your interest in contributing to Calypso, we really appreciate it.
There are many ways to contribute – reporting bugs, feature suggestions, fixing bugs, submitting pull requests for enhancements. With over 10,000 PRs we have merged all sorts of different contributions from within Automattic and from the community, all working together to make Calypso a better experience for everyone.
Just file a GitHub issue, that’s all. If you want to prefix the title with a “Question:”, “Bug:”, or the general area of the application, that would be helpful, but it is by no means mandatory. If you have write access, add the appropriate labels.
If you’re filing a bug, specific steps to reproduce are helpful. Please include the URL of the page that has the bug, along with what you expected to see and what happened instead.
Here is a handy link for submitting a new bug.
Feel free to share your unique context to help us understand your perspective. You can add context tags such as: #journey
#anecdote
#narrative
#context
#empathy
#perspective
#reallife
#dogfooding
#livesharing
#flowsharing
#anxiety
#anxiety-flow
#stresscase
#painpoint
. We'd also love to know how you found the bug: #dogfooding
, #manual-testing
, #automated-testing
, or #user-report
if applicable.
If you’d like to contribute code, first, you will need to run Calypso locally. Here is the short version:
git
, node
, and npm
installed.127.0.0.1 calypso.localhost
to your local hosts file.yarn start
from the root directory of the repository.http://calypso.localhost:3000
in your browser.For more detailed instructions, see Installing Calypso.
Running yarn start
will build all the code and continuously watch the front-end JS and CSS/Sass for changes and rebuild accordingly.
See Development Workflow for details on how to run tests, control what debug messages to receive, and where to look for errors and warnings.
Code reviews are an important part of the Calypso workflow. They help to keep code quality consistent, and they help every person working on Calypso learn and improve over time. We want to make you the best Calypso contributor you can be.
Every PR should be reviewed and approved by someone other than the author, even if the author has write access. Fresh eyes can find problems that can hide in the open if you’ve been working on the code for a while.
The recommended way of finding an appropriate person to review your code is by blaming one of the files you are updating and looking at who was responsible for previous commits on that file.
Then, you may ask that person to review your code by mentioning their GitHub username on the PR comments like this:
cc @username
Everyone is encouraged to review PRs and add feedback and ask questions, even people who are new to Calypso. Also, don’t just review PRs about what you’re working on. Reading other people’s code is a great way to learn new techniques, and seeing code outside of your own feature helps you to see patterns across the project. It’s also helpful to see the feedback other contributors are getting on their PRs.
Consistent coding style makes the code so much easier to read. Here are ours:
When you’re first starting out, your natural instinct when creating a new feature will be to create a local feature branch, and start building away. If you start doing this, stop, take your hands off the keyboard, grab a coffee and read on. :)
It’s important to break your feature down into small pieces first, each piece should become its own pull request. Even if after finishing the first piece your feature isn’t functional, that is okay, we love merging unfinished code early and often. You can place your feature behind a feature-check to make sure it’s not exposed until all pieces are completed.
Once you know what the first small piece of your feature will be, follow this general process while working:
add/video-preview
or fix/1337-language-too-geeky
.add/
, update/
, try/
or fix/
that represents the type of work you're doing. Avoid using the renovate/
prefix in your branch name (it is used by the Renovate Bot that automatically updates our NPM dependencies and your renovate/*
branch will confuse the bot).git commit
.git push -f origin fix/something-broken
. Keep in mind, however, that if other people are committing on the same branch then you can mess up their history. You are perfectly safe if you are the only one pushing commits to that branch.master
make sure you check this list and our merge checklist.
master
to keep the branch history short and clean.master
.Whether somebody is reviewing your code or you are reviewing somebody else’s code, a positive mindset towards code reviews helps a ton. We’re building something together that is greater than the sum of its parts.
If you feel yourself waiting for someone to review a PR, don’t hesitate to personally ask for someone to review it or to mention them on GitHub. The PR author is responsible for pushing the change through.
If you'd like to add a new component to Calypso, please review our new component checklist.
We encourage you to ask for help at any point. We want your first experience with Calypso to be a good one, so don’t be shy. If you’re wondering why something is the way it is, or how a decision was made, you can tag issues with [Type] Question or prefix them with “Question:”.
Calypso is licensed under GNU General Public License v2 (or later).
All materials contributed should be compatible with the GPLv2. This means that if you own the material, you agree to license it under the GPLv2 license. If you are contributing code that is not your own, such as adding a component from another Open Source project, or adding an npm
package, you need to make sure you follow these steps:
wp-calypso
and the full license terms to CREDITS.md
CREDITS.md
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。