Preparing for a WordCamp Contributor Day


If you’re planning to attend Contributor Day at WordCamp Asia (or any other Contributor Day) and indicated you were interested in the Core team, then this post is for you.

The number one thing that I recommend to first time contributors heading to Contributor Day is to prepare before heading to the event. Conference WiFi can be very unreliable, especially if everyone is installing and configuring the required software and tools at the same time. Getting set up can take a good chunk of time depending on a number of factors, even on good internet! 

This is a rough guide to help you show up to Contributor Day ready to contribute!

First, a few notes:

  • Some parts of this guide will be helpful for multiple contributor teams, but this is targeted at Core team contributors.
  • This information really belongs in the various Making WordPress blog Handbooks. However, in the interest of time I chose to publish on my site in order to share this with as many WordCamp Asia Contributor Day attendees ahead of time.
  • I found that most of the information below does exist somewhere in the Core handbook, but it’s not organized into a “guide” (the topics are stand alone).
  • There are some of the details in the Handbook are outdated and need updating.
  • In the coming weeks, I’ll be working with other contributors to integrate this guide into the appropriate places and ensure the information in the handbook is up to date.

Register for WordPress.org and the WordPress.org Slack instance

The large majority of the communication around contributing to the WordPress open source projects happens on WordPress.org or in the WordPress Slack instance. Your first step should be to register for both in that order.

Install required software

In order to contribute to Core, you’ll need the following software installed on your machine:

  • Git or SVN (whichever you prefer)
  • NodeJS (WordPress currently requires NodeJS 14.x)
  • npm (comes bundled with NodeJS)
  • Composer (optional, but highly recommended)

Additionally, you’ll have to choose between one of the following:

Note: There are other tools that can be used to set up a local development environment (such as Local), but the two above are the ones maintained and officially supported.

Decide how you’re going to work

There’s a few options for you to work with the wordpress-develop codebase.

Note: if you chose the Vagrant/Virtualbox/VVV option above, the default is the third option below, but you can change that later.

Forking WordPress/wordpress-develop on GitHub

This option will allow you to submit and work within a pull request on GitHub. When using this option, all of the configured automated testing will run on your code to help verify your change. You can read more about this option in the Core Handbook.

Using WordPress/wordpress-develop directly

With this option, you’ll clone the wordpress-develop repository locally and use that as your codebase. You won’t be able to push any changes or submit pull requests, but you will be able to create patches with your changes to submit on Trac.

Using SVN to check out WordPress

With this option, you’ll checkout the `trunk` branch of the develop.svn.wordpress.org repository to use as your local WordPress site. Any changes you make need to be submitted as patches.

Docker Option

Here are the basic steps to get started with the local Docker environment:

  1. Clone your repository of choice from the previous section. If you’re using a fork that you created, the command will look like this: git clone [email protected]:{your GitHub username}/wordpress-develop
  2. Run cd wordpress-develop to move into the directory created by the git clone.
  3. Run npm install to install dependencies
  4. Run npm run env:start to start the development environment
  5. Run npm run env:install to set up clean installation with the user admin and the password password
  6. Run npm run build:dev to run a build.

You can now load WordPress:

Frontend: http://localhost:8889

Backend: http://localhost:8889/wp-admin/

  • Username: admin
  • Password: password

You’ll find these steps and more details in the project’s README.md file.

Varying Vagrant Vagrants Option

You’ll find detailed instructions for how to get started on the project’s website.

Other Tips

  • Running npm install, vagrant up, or npm run env:start can be network intensive. Run these at home before you leave for the event and confirm everything’s working as expected. Depending on what you work on during Contributor Day, you may need to run these commands again. But having dependencies, virtual boxes, and containers cached locally will greatly decrease the time they take to run at the event.
  • Try creating patches or a PR ahead of time. If you’re able to start working on a ticket before the event, contributors at the event can give you feedback on your work so far.

Here are a handful of other helpful links that will help you be better prepared for Contributor Day.

Special thanks to David Baumwald and Joe McGill who helped review this prior to publishing, and Micah Wood for sharing his (more detailed) document from a previous WordCamp that I borrowed inspiration and the list of links from.


6 responses to “Preparing for a WordCamp Contributor Day”

  1. Thanks for the wonderful writing. I believe that this post helped a lot to the new contributors. As your mentioned, we have to spend a lot of time creating the environment for the core setup locally. If contributors already have it, it will be really easy and helpful.

Leave a Reply

Your email address will not be published. Required fields are marked *