Contributing to Gutenberg: A New Contributor’s Experience

The following is a guest post by Chris Van Patten who shares his experience learning and contributing to Gutenberg. There’s been a lot of talk of Gutenberg’s higher barrier to entry for new contributors. Van Patten is the founder of Tomodomo, a digital agency for magazine publishers.

Over the past few months, but especially over the last few weeks, there has been extensive conversation about the barriers to entry present in contributing to the upcoming Gutenberg editor for WordPress.

Of course, everyone’s experiences are subjective and unique. I can’t pretend to understand what everyone has felt. But my experience has been different than what some folks have been articulating, and I wanted to share my own take.

The Early Days

I’ve used WordPress for close to half my life; almost 15 years now. I remember some of the earliest versions of WordPress: the classic theme, the advent of Kubrick, MP6, up through today.

Early Days of the WordPress Backend

Like many in the community, I’m entirely self-taught. I have no background in computer science, and have no formal instruction under my belt. I picked up code through trial-and-error, tweaking files and breaking my site as I wanted to make changes.

Since those early days, WordPress was always my CMS of choice both for personal projects and for clients with my agency Tomodomo. But even though I had committed to the WordPress platform, my contributions back were limited.

The rules, rituals, and etiquette around posting on Trac seemed arcane and illegible. To this day, I could not make an SVN patch if my life depended on it. And much of the core code, imbued with years of history and backwards compatibility, was hard for me to pick apart.

So instead, I contributed in other ways: open sourcing simple custom plugins I was building, organizing WordCamps and meetups, and speaking at WordCamps around the globe. But it always bothered me that I couldn’t find a way to get those elusive ‘props’.

(Okay, so I did actually get props on one release, but I am convinced it was a mistake; I had neither opened the ticket or provided a patch.)

Going… Going… Gutenberg

When I first learned about Gutenberg and started exploring, I was apprehensive. At first it seemed scary. My JavaScript abilities didn’t extend beyond jQuery. React was inscrutable and it seemed like I’d need a doctorate to understand some of the ideas behind it. I still don’t understand how Webpack works its magic. Does anyone, really?

But the possibilities of the new block interface were too enticing to ignore, so I started diving in and figuring out how it worked. In those halcyon days (aka earlier this year), Gutenberg was still pretty rough around the edges, and there were a lot of opportunities for improvement. I started lurking on the GitHub repo, reading issues, examining the code, and generally trying to wrap my head around what the heck was going on.

As I was playing around with Gutenberg for a client project, I started reporting issues: simple things, like user interface bugs. I started commenting on tickets, usually offering suggestions for a particular feature, trying to advocate from the perspective of independent developers.

I even filed my first pull request! It was simple. I updated the README to include the day and time of the weekly #core-editor meeting (Wednesdays at 1pm UTC, if you’re wondering). It was an inauspicious beginning, but I was excited to get it merged.

Over time, my knowledge grew. It was like my early days in web development, learning a CSS property here, and an HTML element there. I learned what a component was and how you could reuse them in different situations. I learned about JSX, and ES6, and some of the other crazy acronyms you encounter in Gutenland.

As I was building more with Gutenberg, I was also finding new ways to build Gutenberg itself. I was able to understand more of the discussions, and offer my thoughts and suggestions. I started opening pull requests, largely dealing with design issues but also solving small bugs and quirks. I made a point of attending the weekly meeting I had previously added to the README, chiming in when I felt I had more perspective to share.

Today I have 25 new issues and 27 pull requests under my belt, in addition to dozens of comments on existing tickets. I’m a ‘member’ of the Gutenberg team on GitHub, and try to find time every day to triage new bugs or review pull requests. It took me most of the year to get to that point and it certainly wasn’t always easy. I still have so much to learn.

When I hear about how difficult it is to contribute to Gutenberg, I can’t reconcile that with my own experience. That’s not to say it’s a breeze: Gutenberg does things very differently than WordPress core, and there is undoubtedly a learning curve.

Advice for Contributing to Gutenberg

If you aren’t comfortable coding from day one, there are so many other ways to contribute. Read through issues and add your own ideas and suggestions. Try testing and replicating bug reports. Hunt through inline documentation for typos and grammar corrections. All of these are valuable, and always appreciated.

As you absorb the Guten-way through osmosis, you’ll find that the code isn’t as hard as you think — it’s just different. The intelligent people who build Gutenberg have done a great job at hiding away the ‘computer-science’ bits so the rest of us don’t have to worry about data binding and other complex ideas. I still cannot explain state management, data stores, or context APIs but I have managed to find small areas of the code to improve.

This isn’t to deny anyone’s frustration or confusion with Gutenberg and its development. Documentation is still lacking in many places. Some of the APIs are unintuitive. The tooling isn’t the simplest to set up. These are real problems, and I don’t want to pretend they don’t exist; we can undoubtedly do more to make Gutenberg development easier.

And of course I have privilege to check: I’m lucky to have the time to spend in the GitHub repo, experimenting with code, and participating in weekly meetings. I recognize that’s not a reality for many people.

If you can’t find the time, the Classic Editor will continue to be an option, and there’s no shame in prolonging the upgrade. It may take time for the Gutenberg experience to be as intuitive as we would all like it to be, and waiting for that is totally reasonable.

But if you open yourself to some new ideas about what WordPress can be, and can make the time, you may end up surprised at how easy it is to contribute. If you get stumped, pop into #core-editor or the forums. Don’t be afraid to post a bug report or suggestion; we might consolidate it with another issue if it was previously reported, but the additional information is still valuable. Every experience matters.

I’m incredibly excited about the future of WordPress with Gutenberg and to finally be a real WordPress contributor. We have a long way to go, but that means there are still many exciting ways to make a difference. The project will only get stronger with more independent community voices chiming in.

I hope you’ll join us!