Last week I had the privilege of joining Abby Cabunoc Mayes as a guest host for an episode of GitHub’s Open Source Friday where we spoke to Mitchell Hashimoto about Vouch and this “Eternal September” of open source. Around 43:15 as we were talking about our humanity as maintainers and how our own behaviors have changed, I said something about “the joy of being a maintainer” as a quip but now I’m realizing it isn’t just a quip!
When I decided to stop working on WordPress full-time, it was in fact because I had lost the joy – amazing things were happening, but instead of feeling excited to bring up other developers and contributors, I felt resentful. Something had gotten lost, and while I’m glad I realized it and made a change for myself, I have found myself once again working on quality of life for OSS maintainers at GitHub. And in that work, what we want to do is find ways to bring back that joy… or at least try to reduce the things that get in the way of it.
So what constitutes the joy of being a maintainer? For me that’s:
Seeing a new handle (username) start showing up consistently and not just with code
Really, any consistent non-code contribution, especially if you triage bugs and/or write clear reproduction steps
Meeting people IRL after working with them a bunch as said handles, especially at WordPress Contributor Days
Watching a contributor find an area they’re really excited about and build confidence and leadership in it
Having built up so much knowledge I can debug weird things really quickly
When I can’t debug quickly, still managing to puzzle out a problem, especially the really gnarly ones
Giving a contributor a half-baked idea and watching them run away with it better than I could have
Blaming a bit of code and finding out that something complicated has been sitting there working for the last 20 years
Blaming a bit of code and discovering that past me was smart, actually (I also find that past me was an idiot about as often)
Watching the WordPress download counter reset and skyrocket when a new release goes out – it used to take days to get to one million; now it’s on the order of an hour thanks to scale and autoupdates
I’m sure there’s more, but for now: back to work on making things better for maintainers everywhere, not just through defense mechanisms and reacting to AI and poor etiquette, but by making space for what brings you joy ❤️
Note: this is a lightly edited version of an internal work post I wrote in April 2025 before Copilot Coding Agent was released to the public.
I’ve been playing with Copilot Coding Agent a bit lately, and it’s been really interesting for me to realize that my thoughts haven’t really been about AI so much as how strongly the output reminds me of incoming contributors to open source software, and all those non-code maintainer skills coming in handy and what I can work on sharpening again. Similar things apply to earlier-in-profession developers too, and with new hires joining our teams next week, this feels especially good to be thinking about right now.
The thing is, when you combine very eager volunteers with low context, you’ll tend to get additive solutions. And that makes sense! They’re thinking about how to make something work, not “what are all the things that happened leading up to this that caused this that maybe need re-examining” – root causing, if you will. But just because it makes sense and maybe is even expected doesn’t mean that we can’t help steer contributors, human or AI, in better directions through the way we describe the problem space in a well-written issue. Practices of keeping good hygiene between discussing problem definitions (issues) and feedback on solution proposals (PRs) also seem more important than ever – there aren’t always solution proposals to be had for a given problem, and sometimes there are multiple to think through.
So what are some things we can all think about as we grow ourselves and support the journey of others? Here’s what I’m thinking about, and I’d love to hear and talk about yours in the discussion!
Keep issues focused on the problem definition and context – centering them around a specific solution tends to narrow our thinking when it comes to the solution. Of course, sometimes it’s a straightforward bug that’s the problem, so don’t forget nuance either.
Clearly written reproduction steps: one of the things I encourage giving visible code-equivalent credit for in OSS, because it’s hard to describe reproduction steps in a way that is broadly understandable and doesn’t overly rely on screenshots. Oh and hey, if you do use screenshots, remember to include alt text – it’s good for both humans and the machine.
Including references and links for easy access from one place – building context from code archaeology is hard! This doesn’t have to happen when an issue is first written – it can be added later as you dig around and find things.
Ensuring non-durable artifacts or content behind auth like Slack conversations are copied over and/or summarized, especially when decisions are made.
Raising each other up and remembering to include all these skills as a part of how we think about impact and excellence at work and beyond.
Being willing to try to explain again in a different way to steer contributors onto a given path.
The machine is imperfect just as we are, and with AI it’s even clearer how it reflects our own imperfect communication back at us. I’m looking forward to cross-repo support someday with Copilot Coding Agent, because I can see the promise in using the tool to reduce the friction getting started with resolving audit-discovered issues. So while that’s not here just yet, we can still get a start on refining the way those types of issues are written to help get to a reasonable solution faster, whether done by human or Copilot.
I find myself most recently the engineering manager for accessibility at GitHub – an honor and immensely fulfilling to make improvements big and small for all of our users now and in the future. This isn’t an exhaustive post or a tutorial but rather some things I keep thinking about as we both use and work on AI tools.
Accessible interfaces 🤝 LLM context
Working on the accessibility of a product often involves a push-and-pull between prioritizing compliance and focusing on experiences. We need both but can’t always tackle both at the same time. One strong case for the compliance side is that it’s often about structure and semantics, things that are measurable and detectable in a more objective way. If you think about it, assistive technologies are programmatic consumption of rendered pages. What else does programmatic consumption of rendered pages? LLMs! If compliance alone wasn’t enough of a reason to prioritize that work, consider the additional benefit to anything doing programmatic understanding of your product and/or content.
Enabling even more users
With greater programmatic usability comes more ability to use whatever tools suit you to help navigate and use an interface, whether that’s chat or automations or otherwise. How many people have ideas that never come to be realized because they cannot access what they need to bring them to life? On this topic I’ll share a video that brought me to literal tears.
Accessible by default
I’ve heard it said that where we are with AI is the worst it’ll ever be, and I think that’s true. We will continue to learn and apply what we learn to the tools, and for things that really should be table stakes baseline aspects of what it means to be a developer like accessibility (no, your job is not done if it’s not accessible), the machine should be held to that same standard. New developments like MCP servers make me much more optimistic we can get there, but it remains a space to actively push on especially as we focus on agents and the production of larger blocks of code.
I posted this reflection on our internal blog on my 10 year work anniversary in August:
Back at the end of July 2011, I had just returned to Rochester, NY from WordCamp Boston, which had been more of an incidental happening while in Boston for other reasons, and was looking at Twitter for the first time in a while because that seemed to be the thing that all these WordPress people were doing – hashtagging and tweeting about things. At that moment, I was holed up in our bedroom while my husband had taken over our living room with 3 other doctoral music students, all of them studying feverishly for comprehensive exams before each of them headed off to a different state for their first professorship. In our case, we were headed to Wichita, Kansas, and because it was only a one-year position, it was time for something new to ground us. For me, I knew I needed to find one of those remote jobs I had started to hear about because my job as a mid-level PHP/MySQL web applications developer at the music conservatory where I had also previously been a student couldn’t really move with me.
I saw a retweet from Brad Williams (remember when retweets were a manual copy-paste where we would type RT @whoever at the beginning?) from a @jakemgold saying that he was looking to hire a full-time WordPress developer to work from anywhere. I didn’t know who Jake was, and only followed Brad because he had co-written a book I found helpful, but it seemed serendipitous in the way I have a tendency to believe in and follow. So I messaged Jake, set up a call for later that day, told the living room study group “I think I have a job interview later”, did the interview, and then told the same group “I… think I have a new job?” If you know anything about how involved the music academia hiring process is, you’ll know that I was not very popular with our friends that day.
RT @jakemgold: Recruiting full time #WordPress developer / PHP engineer. Work from anywhere. Interested? Get in touch!
So we moved to Kansas and on Monday, August 15, 2011 I started as a Web Engineer at 10up. As it so happened, I was the first full-time hire! I knew absolutely nothing about working at an agency, or what caching in WordPress was, or anything about Git besides that it was confusing (it is still frequently confusing, to be fair, but at least now I usually know what went wrong), or really much of anything that we take nearly for granted today. It was me, Jake, and a TechCrunch-focused contractor named Luke who some of you may still remember. In the literal decade since, we’ve grown to almost 300 people looking at revenue in the 8 figures, I’ve been through several title and role changes, grown two humans myself, and became one of 5 lead developers on that piece of software we were always building on top of, going from 13% to more than 42% market share, all with the steadfast support of Jake and 10up at large.
At this point, you probably have a feeling about where this is going: yes, it’s time. I have wrapped up my long tenure at 10up and will be taking on my next challenge in the new year, after a little breather.
Once upon a time, if you asked Jake Goldman who the dream “we made it” client would be, he would have said “The White House”. And wouldn’t you know it, just as I hit a fresh global-pandemic-enhanced round of “what am I even doing with my life” late in 2020, the opportunity to work on the actual White House site for the Biden-Harris Administration and bring my ideal vision for a visually-driven editing experience to life basically fell into our laps. We absolutely killed it – I am beyond pleased with the outcomes, and learned so much in the process. Yet despite all the things I know we can do from here for our clients and for each other in the WordPress development space, I have found myself ready to close this chapter of my working life. It’s the capstone I didn’t know I was looking for.
If I’m being fully honest with myself, I’ve been on the path to this decision for more than two years. Part of my success in WordPress as an open source project has been that I’m generally comfortable with living in the in-between before making a decision, while still disliking the indecision enough to make sure I keep moving toward an end point. And that’s what happened here – I wasn’t sure I wanted to stay but wasn’t ready to leave 10up yet either, for whatever reason. I even took a 3 month break, barely touched a computer, looked at other jobs, and came right back. Maybe I felt like I needed that one last hurrah, maybe I hadn’t fully accepted that I would be leaving a large group of people whose company I deeply value, maybe some spidey sense was telling me that I should just wait a bit longer because something was going to happen. In hindsight I see that a really big thing did happen – I returned from my sabbatical in March 2020, just in time to see the world grind to a halt, where the changes in home life were incredibly disruptive in a way that would not have gone well on top of a new job.
In one last showing of why it’s been so hard to imagine leaving my beloved coworkers, my teammates Jeff Paul, Darin Kotter, and Tung Du, with an outside assist from Mel Choyce, surprised me with a WordPress block plugin they had created in my honor: a fully functional Winamp player you can insert into your content. Mel even designed custom skins inspired by my keyboards and general aesthetics for somebody to implement someday soon. You better believe I cried when they showed me 😭 There’s nowhere better than 10up if you’re into WordPress, so you know I can’t leave without one last reminder that “10up is hiring” and it should be your top pick for this type of work. I mean, just look at these!
As for what this means for my work with WordPress, I honestly don’t know! I’m still me, the same thinker and holder of many years of knowledge and history, and whether my job sponsors me or not I am still able to contribute to WordPress. I do know that over the last few years I have not been nearly as active as I once was, and am happy to continue to background support the people who currently do the bulk of the work to be their best selves without focusing on whether my title of “lead developer” is still important or chasing some concept of legacy. I don’t think I want to work on WordPress itself full-time again, and I think that should be okay – I have ideas and wants, but no real drive to manifest them myself anymore. I feel very good about the current direction of the project (yes, especially the editor) and the wonderfully smart and kind people who work on it, and am thankful to have been a part of such a great community and project for such a long time. You definitely have not seen the last of me – after two years without, I’m ready to hang out with all of you at a WordCamp again, hopefully in the near future.
I am incredibly proud of everything I’ve accomplished at 10up and with WordPress, who I’ve become and who we’ve become, but I’m missing something. It’s an honor to be able to shape what WordPress developers do and how we think about things like the critical nature of open source and the intersection of UX and development, but I want to learn and to coach again, the way I did when I was still a musician. That’s not to say I couldn’t do that in my current surroundings, but my instinct is telling me that I need to explore this in the broader tech product space, and in a way that isn’t quite so publicly visible. I have signed an offer to be an engineering manager for a great team doing the kind of work I love, so I’ve got a pretty good sense of direction now and am deeply at peace with my decision to do something new, but I’ll leave that reveal for my first first-day in over a decade. 🙂
I’ve spent the last 8 months telling anybody I talk to about custom WordPress block development that they were way less scary and much easier than I thought they were going to be as somebody with minimal React experience, and that achieving a 1:1 editor experience where you manipulate directly in the content area instead of metaboxes or panels really comes alive when you reuse the same markup and CSS from the front-end and leverage the React components the block editor ships with. Because of that, I think a big game-changer for adoption and shifting thinking would be to find a way to unify templating between the front-end and the editor, essentially swapping the places where you output content with the corresponding editor component.
So what had happened was… I was once again going on and on about this to Mark Jaquith, who blessedly seems to enjoy walls of text from me about programming puzzles, and it turns out he’s been thinking about the same thing as he gets into block development. A weekend later, and:
Weekend exploration, egged on and sparked by @helenhousandi:
“What if building custom blocks for the Block Editor was as easy as supplying attributes and a block of HTML? What if this produced React editing code and PHP rendering code without a build step?” pic.twitter.com/r86Phu88SX
