In the summer of 2019, I was asked to help out with a WordPress release. A few months before, the Core Team representatives reached out to other teams in an effort to increase the diversity of the release teams, and I started seriously considering it.
At the time, I was already heavily involved in the WordPress ecosystem and was in my second year as the WordPress Community and Partnership Manager at SiteGround, but I had no experience whatsoever on how WordPress gets done from a Core point of view. Still, when Josepha Haden, WordPress.org Executive Director, pinged me, I said yes without hesitation. And it proved one of the most challenging and rewarding experiences of my life. Here is how.
An Accidental Contributor: My Path in Tech
From an early age, I seemed to be predestined to become a developer. My parents are programmers, they started in the sixties, and I got my first personal computer in 1982 when people in Italy didn’t really have an idea of what those were.
I followed after their work ethos and I thought that their job was fascinating, making a machine do what you want, but I was drawn to other career options. In fact, I didn’t really know what I wanted to do when I grew up, but computers and websites kept being a big part of my personal and professional life.
While back-end programming was never something that interested me, I found myself taking a class on web design in 1999, then signed up for a degree in Arts and Multimedia in 2004. I finally found WordPress in 2008 and started making a living off of it in 2010.
Soon, I realized my true skill was helping clients who were coming to me with a request for a website to better focus on their “why” for the website and think about their business and marketing strategy before they hired me. I wrote books on business planning, productivity, and websites. I also started giving talks at WordCamps and other events to educate freelancers on those topics.
In 2015, I randomly met some people who were involved in the WordPress community, which led me to start contributing too. I didn’t have development skills so I never thought I could contribute to OSS, but it turns out that was unnecessary. I met people who pointed me to the many different teams that make WordPress and started being active in Polyglots first and Community later.
I kept working on my business, but the more I contributed to WordPress, the more I wanted to find a way to help thousands of people at a time. My outreach efforts of giving talks, helping community organizers, and writing content needed to scale.
This is where I met SiteGround. In the summer of 2017, they were looking for a Community Manager and despite not being one by trade I decided to apply and got the job. Joining the company allowed me to have sponsored time to contribute to WordPress. It also allowed me to tap into the collective knowledge of my colleagues when I start cooking up new ideas for the project.
So I said yes without hesitation, but the truth is that this yes was almost five years in the making. In addition, I felt that Josepha and SiteGround trusted me to do a good job. In return, I trusted the WordPress community to help me figure out all the things that I needed to learn.
How WordPress Gets Done
The other encouraging factor was that ever since WordPress 5.0, a release was no longer made by one person, as it used to be for years, or a person with a couple of deputies. Now there was a whole team at work, affectionately known as “the squad,” so there are many hands on deck.
A Lot of Communication
During a release cycle, there is a lot of communication. There are blog posts from different Make teams. At each stage of the release, there are blog posts in the News section of WordPress.org. There is constant chatter in the public Slack channel and there is a private one which is the safety net for the new people that initially might feel intimidated by asking questions in a large public channel.
The Different Roles in the Release Squad
The thing that I love the most about this model for the release is the variety of roles that it includes. There are developers, designers, marketers, technical writers, and project managers. WordPress is not only made of code, and it’s great to see all these different skills coming together to contribute to its release.
The role of the Release Coordinator (the one I covered for WordPress 5.3 and 5.4) and of the Triage PM (role that was covered by the excellent David Baumwald for 5.3, 5.4, and 5.5) is to try to keep an eye on all the moving parts. And I say try because it’s nearly impossible. This is why there are focus leads for the different parts that are getting worked on.
Matt Mullenweg is the project lead and has been the release lead since WordPress 5.0. He comes up with the high-level roadmap and the focus projects. But beyond that, he is not involved with the day-to-day life of Core development. In over one year of being involved in Core releases, Matt asked only once to add a feature.
I am annoyed when people think that everything that happens in WordPress is because Matt wants it that way. It diminishes the role of all the people who care about the project and take it upon themselves to move things forward, to shepherd issues, to champion tickets, and in general to commit to contribute to make WordPress better for everyone, no matter if they do it for one ticket or work on it full time.
Component Maintainers and Core Committers
A group of people who are instrumental in shaping a release are the component maintainers. They are responsible to look after a certain component that makes up Core and see how tickets in that area are proceeding. They are the ones who can evaluate if a ticket is ready to be merged.
Once a ticket is deemed ready, Core Committers enter the scene. They do a final review of the ticket. They might request some changes, or make the changes themselves while committing. This is the thing that surprised me the most probably. I really didn’t think that a commit could take hours, but it definitely can. In the releases I coordinated, I definitely observed not a lot of engagement from maintainers and committers, and this is very demotivating for people working on tickets. Not everything can go into a release, even if the patch is ready, because there aren’t enough people to review, give feedback, and ultimately commit. With few resources, you have to make choices and those will not always align with each WordPress user or contributor preferences.
This is probably one of the biggest challenges WordPress will have to tackle moving forward: How can we reactivate people who can give a big help?
The Release Party
Despite these issues, things get done and when the release is ready, we celebrate with a party. I don’t know who started calling them Release Parties or when they started. What I know is that for 5.3 and 5.4, I hosted quite a few, and they were all a lot of fun.
On the day of one of the steps of the release (it might be Betas, Release Candidates or General Release) the Core channel gets very active: a lot of people come online to see how the version of WordPress gets released. There are multiple steps and different people involved with different tasks. The release steps are documented in the Core handbook and are followed publicly so everyone can see them all.
The biggest party is the general release day; there is one specific moment which is incredibly powerful. WordPress has a download counter, so before releasing the new version, the squad takes a screenshot of the previous one, we all say goodbye and welcome the new kid. Despite everything being virtual, this moment is almost tangible and will never cease to move me. We made WordPress, once again.
12 Months as a Core Contributor
While I was writing this article, it occurred to me that I have been a Core contributor for a year now. I still have my full-time role at SiteGround, which at times I found hard to juggle, so I have to give my team credit for their support.
I still can’t write PHP and despise JavaScript deeply, but when I look back, I am incredibly proud of the changes that have happened in the past 12 months. I can not take credit for all of them, but I am happy I was able to be somehow part of them.
Release Schedule
One thing that a lot of contributors asked for was a mid-term schedule of releases, to better fit them around their work and personal calendar. Being the new kid can be hard because you don’t know the whole history and background of why things are done a certain way, but that is also a perk. You are free to restart conversations. After discussing it with the squad and other teams, it was clear to me that it was just a matter of “who is going to bring this up with Matt”. And so I did. A couple of days later a tentative release schedule until WordPress 6.0 was published on the Core blog, and we have been using it ever since.
Bigger Release Squad and Mentorship
The release squad is also getting bigger with every release. Many teams are involved in making it and affected by it. It’s important for all these teams to be represented in the process. In WordPress 5.5, there are several new roles, and in 5.6 there will be even more: Test, Documentation, Support are all vital components of what makes WordPress great, so having their feedback while the software is in active development is important.
And it’s important to have mentors. This is a major improvement that Josepha introduced in WordPress 5.3. The release squad is not only made of focus leads, but there is a growing group of mentors able to help new contributors learn the ropes. The idea is that those people will eventually become mentors and teach new people. This is another great way to have more and more people involved in Core, with different skills and backgrounds.
And this brings me to the biggest change (and challenge) of all. WordPress 5.6, which is shaping up to be a massive release, will have a squad entirely made of women and people who identify as female. Like a lot of things in WordPress, it all started with a “Thinking out loud” moment and is now a reality. Work on this release will start very soon, and I am excited to be part of it as a mentor.
WordPress Needs Your Help
I wish I could say it is all unicorns and rainbows, but it’s not. The number of people actively involved in making this project a reality is still very small compared to the magnitude of its reach.
I am very much a doer, so I wish people took the time and energy they take into critiquing WordPress and turn it into active contribution time. Yes, sometimes it requires being very stubborn about a ticket and it requires to follow up on it relentlessly, but I still think it’s worth it.
Active participation also means leaving constructive feedback in tickets or offering to take notes during dev chat. That is the curse and the beauty of a massive project. There is always something to do!
In the last few years, I have also seen an increase in contribution from different kinds of companies. At SiteGround, for example, we mostly contributed to events and the community for years. We sponsored, and we volunteered, we were organizers and speakers. We worked a lot within the Spanish WordPress community to help it develop and grow, and now it’s one of the largest in the global community. In the last year, we have increased the hours we dedicate to more technical teams. I am still active in Core as a mentor and as the team representative. One of our WordPress engineers, Stanimir Stoyanov, is part of the Security team, and one of our JavaScript Engineers, Kiril Zhelyazkov, is now dedicating a couple of days per week to Gutenberg.
These topics align with our values, so it was a natural progression for us to become more involved.
Finally, I hope to see people get involved in a proposal I published a few days ago in the Core blog about end-to-end tests. Right now there is one, and I’m sure we can do better. Again, developers are not the only ones needed. Users are the rarest contributors and probably the ones the project needs the most to finally have some user testing in place. I am not a developer, and I’m happy that non-developers can make an impact.
My Personal Concerns and Hopes for the Future of the Project
When I started contributing to Core, I started a note on my computer with some observations. Not having 17 years of experience in the project helps me see things without bias, and not being a developer helps me see the project more as a living, breathing body, instead of components or tickets. Allow me to share my concerns, hopes, and dreams for the future.
Component Maintainers and Core Committers: You Are Needed More Than Ever
At the time of writing this article, the project has about 60 committers and 60 component maintainers, with a lot of people pulling double, triple, and sometimes sextuple duties. But the reality is that in WordPress 5.4 and 5.5 hundreds of commits were made by Sergey Biryukov. I am incredibly grateful for Sergey’s work. At the same time, I feel like we are inadvertently building a bus factor into Core. The majority of the people with Core Commit access did not commit one ticket. Similarly, I reached out to all the component maintainers to hear about their plans for the upcoming releases and only about 50% of the components replied.
How do we make sure that the people who have the power, and thus the responsibility, to help with committing and shepherding tickets are involved? But also, how do we encourage people to step down and declare themselves inactive so new people can step up?
My career spans over 25 years in different industries, and one thing remains the same: when people see there is someone else filling a role, they will be less motivated and sometimes even intimidated to step up. Scarcity not only drives purchases, it drives new engagement.
The Community Team, for example, maintains a list of deputies and their different statuses. I have been wondering if Core could do something similar so when new people want to step up they can see at a first glance which components are missing maintainers. People who complain about “The Core Developers” will not see them as a blob, but as individuals who at any point in time might be inactive for a period. When you see that there are actually only a few people actively reviewing and committing, you might be more prone to understand why not every ticket can make it to the finish line.
Documentation Is the Highest Form of Generosity
I say this every time I speak about contributing to OSS: documentation is frequently lacking. Oftentimes, what is there is outdated.
How do we make sure that documentation is not an afterthought but is baked into the development process?
There is a lot of work put into writing dev notes for the changes that affect development, but that is not the only documentation that is needed. Some of the processes described in the Core handbooks are outdated, some are missing because they live in experienced contributors’ minds.
As a big fan of Gutenberg and rich, engaging text, I wish our handbooks would fully leverage the power of the block editor and be more inviting. Right now they are a wall of text and whenever we tell people to look at the handbooks I feel my heart shrinking.
Possible solutions, which I am not sure are technically doable, but a girl can dream: sync with GitHub to solve at least the version control issue. Then recruit, recruit, recruit and work with Documentation, Meta, and Design to provide useful, engaging, readable, easy-to-scan handbooks.
Keep Track of the Moving Parts and Work as One
The other thing that I notice often is how teams, focuses, and components work in silos.
This is absolutely not done to be gatekeepers, it’s just how every team self-organized over the years.
We need to find a way to have a bird’s eye view of what is going into the next release and what are all the moving parts.
Trac is very granular and you have a number of ready-made reports, you can filter by milestones and see how many tickets are in each component, but that is just part of the story.
Yes, I am talking about finding a way to manage the project as a whole and not as bits and bobs.
Enter GitHub. At Some Point.
This is not happening anytime soon, but I hope it will eventually happen. Move development and project management of WordPress to GitHub, like Gutenberg has been doing.
I know that for many it will be an incentive to contribute to WordPress in a way that is more familiar. It will lower the bar to entrance, which is always welcome. With some handy tutorials, it will allow non-technical people to contribute to documentation, testing, and project management.
The Future is Bright
Despite all the issues, or maybe because of them, the future of WordPress is bright.
I have been lurking around multiple teams in these years, and lately I notice more people coming on board, more people being involved in each release, more people stepping up in leadership roles in different teams. I have also noticed an increase in diversity, which is always a welcome change.
Bottom line: WordPress needs all of us to make it happen. I hope to see you on board!
Thank you, Francesca! It’s a wonderful and inspiring insight into how the Core team works. Love the timing, too.