I’m no stranger to public speaking, but a couple months ago when I came across the concept of Ignite talks, I was in for an interesting new challenge.  If you haven’t heard of Ignite Talks before, it’s a format of public speaking where your entire talk is comprised of 20 slides, each 15 seconds in duration, which auto-advance underneath your talk for a total length of 5 minutes.

I’m used to giving talks more in the 45-60 minute range (Looking to host a workshop at your company? Let’s talk.), so building a talk that told a complete story in 5 minutes was going to be something different for me. Couple that with the fact that I didn’t have control over advancing my slides, and it seemed I was in for more of a performance than the workshop-like talks I was used to.

In the end, I took my inspiration from a passage in Seth Godin’s Linchpin and spoke about times when opportunities in my career made me fearful and unsure.

The audience that night got to hear about how I deleted an entire website with no backup. They heard how saying “yes” to the biggest project I’ve ever taken on has gotten me to where I am today. Fear played a role in both of those actions. Godin provides us with a framework for how to deal with fear when it comes to opportunities. He writes:

What separates the linchpin from an ordinary person is the answer to this question.  Most of us feel the fear and react to it. We stop doing what is making us afraid. Then the fear goes away. 

The linchpin feels the fear, acknowledges it, then proceeds.  I can’t tell you how to do this; the answer is different for everyone.  What I can tell you is that in today’s economy, doing it is a prerequisite for success.

To me, that’s super powerful.  Everyone encounters fear at some point in their career and how you deal with can set you apart or it can hold you back.

It turns out that this Ignite talk became the perfect example of such an opportunity. I can’t remember the last time I was nervous to give a talk in front of an audience. But as I stepped up and took the microphone off the stand, my hands were shaking a bit.

But like the other times I’ve embraced fear in my career, everything turned out OK. My slides got ahead of me a little bit, but I was able to catch up.  5 minutes flies by when you’ve got the lights on you and the mic in your hand.

I shared great stories with audience members after the event and had a great time hearing the other speakers share their experiences.

Taking on this new format was a bit of a risk for me, but it was absolutely worth it.  If you think you might enjoy doing the same, head over to ignitechi.org and click on that big “I Want to Speak” button.

Feel the Fear. Acknowledge it. Proceed.

I hope to be hearing from you at the next Ignite Chicago!

Share on:

One of the benefits of WordPress is that it’s open source and improving every single day thanks to the WordPress community. Yet, few people know exactly what that process looks like. When you identify a bug in WordPress, where is that information reported? Who fixes it? And how does it get pushed out to over 28% of the web in the next WordPress Core release?

This post is a text version of my talk given at WordCamp NYC 2017. The slides are on found on SlideShare and a video version is available on WordPress.tv.

We’ve discussed open source contributions on the blog before, but how does such a large project manage this process? WordPress uses a tool called Trac, which is “an enhanced wiki and issue tracking system for software development projects”. As an open source project, all the discussion and work happening on Trac is visible online at https://core.trac.wordpress.org/. Trac handles all the incoming code through a version control tool called SVN. Let’s look at this process in more detail.

What does the process look like?

All changes or bug fixes to WordPress start out as a ticket. With a ticket, the reporter details the bug they’re seeing or the feature they’re requesting. If you’re filing a ticket, it’s important to be as specific and provide as much information as possible. This reduces ambiguity and allows that ticket to get started faster.

Once a ticket is on Trac, discussion ensues on that ticket. This discussion can involve anything from debating approaches, whether the intended functionality should be in WordPress at all, or even clarifying the initial ticket if it wasn’t specific enough. At a certain point, the discussion clarifies enough information and it’s time to start contributing code.

Getting set up to contribute

First, you’ll have to have a local environment set up with the latest version of WordPress. Further information on how to set up a local environment is available on make.wordpress.org. Once your local environment is set up, it’s time to pull down the latest code. The easiest way to do this is to use an SVN client and handle the entire development process in SVN. But, if you’re more familiar with Git, you can use Git and GitHub to create your patches.

Now that you’ve got your environment set up, you can go about writing and testing your code needed to fix the bug. If you’ve confirmed that your changes fix the bug, you can generate what’s called a patch file. A patch file is a text file that tells Trac and other developers what you changed. It looks something like this:

That patch file notates that I added three lines of javascript code. Once you have this patch file, you can upload it to Trac to share with the community. Contributors add more discussion and patches until they agree upon a solution.

As a slight sidebar: One of the most important things you can do when contributing is to make sure you follow the coding standards. This ensures that the coding style of WordPress is consistent, even with hundreds of different contributors. For more information about the WordPress Coding Standards, see codex.wordpress.org.

Once the latest patch is ready to go, this ticket gets assigned to a future release. Next, a core committer commits your code and it’s released! With that, your code goes out into the world and you’ve helped make the web a little better.

How do I actually get started?

In addition to Trac, WordPress manages discussions around tickets and contributions in the Make WordPress Slack team. Joining this team allows you to see the discussion around WordPress development. The first step to contributing is to head over to make.wordpress.org and join the Slack team. From there, you can join the discussion and meet some of the people who are already helping out.

All other information about contributing to WordPress lives on make.wordpress.org. This includes which teams need help, what’s they’re working on, and more specific information about the contribution process.

If this is your first time contributing code, check out tickets that have been tagged for first-time contributors. These are bugs that are either very well-defined or very specific to one area of WordPress and won’t need very in-depth knowledge to fix. These are perfect for getting used to the contribution process.

That’s it!

Now that you’ve got a handle on the process, get out there and start contributing! There’s so much more than code that you can contribute: documentation, design, or even helping with project management. If you’ve got any more questions, don’t hesitate to reach our via email or Twitter.

Share on: