So what do I actually do as a full-time WordPress core contributor? I read, write code, test, attend meetings, and sometimes I do support and write documentation.
I work from home and I start my day early, often around 5 in the morning, so that I can have the afternoon off. Working from home and having flexible working hours are important because they allow me to help my disabled partner with any urgent needs during the day.
It also means that my working hours overlap somewhat with contributors from all over the world, not only Europe.
The first thing I do after breakfast is log in and let my colleagues know that I have started my day.
Keeping software and local WordPress copies up to date
Next, I start up the software I use, including Chrome, VSCode, Docker, GitHub desktop app, and sometimes Local. This is also when I take the time to do any software updates.
Other tools I use and keep open frequently are the WordPress Block Editor Handbook, the Developer Reference, and, Chat GPT.
I have to make sure that my local copies of WordPress trunk and Gutenberg trunk are up to date. I maintain a separate fork of wordpress-develop, but not of Gutenberg.
The number of other-than-trunk WordPress installs that I have is… a lot. I don’t always use trunk, most of the time I use the latest released version, like 6.7.2.
Occasionally I use other plugins than Gutenberg! For example the Beta Tester plugin, Yoast SEO, Query Monitor, Create Block Theme, and a plugin to reset the database.
What about WP-CLI?
Guilty. It’s on the long list of things I know I should use, but don’t. I blame it on my lack of ability to configure it in a way so that it works on Windows. You see, I work on both macOS and Windows, sometimes based on what I feel like, and sometimes based on what I plan on doing that day.
Creating the daily to-do list
I start by glancing through emails and notifications on GitHub and the WordPress Slack to see what I need to prioritize. This usually gives me a to-do list of 5-6 things such as responding to requests for reviews, or applying code changes requested during review of my own pull requests.
This to-do list is never set in stone, as notifications continue to flood in throughout the day.
Tip: If I don’t know you, and you only message me “Hi”, I won’t reply because I won’t have time: Instead, let me know what you need right away.
I don’t jump straight into these tasks unless something is on a short deadline.
Instead I visit the support forum for the Twenty Twenty-Five theme to see if there are any new questions or issues that I can help with. If I find that something will take more than a few minutes, I will add it to the to-do list and get back to it later (this may be days later).
Then I check the list of the latest tickets on Trac. Here I am looking for new tickets in the Bundled Theme component, or anything else I can help with. I may triage tickets that are support requests, duplicates, that need more information, or that should be closed and re-opened in the Gutenberg GitHub repository. Many new tickets that are related to the block editor or blocks are still opened on Trac first.
Admittedly, I don’t test all new bug reports that people submit on Trac. I read them, but sometimes they are related to areas that I have no expertise in.
Then I do the same thing on the Gutenberg GitHub repository. I read through new issues, do some quick testing, add labels etc. After ‘making the rounds,’ I will take a short break from the screen. I might go refill a water bottle and maybe do some light chores around my home.
Focused work and meetings
After that there are a few hours of focused reading and coding until I have a scheduled zoom call with the rest of my team. I spend a lot of time reading past issues and pull requests. Solving bugs is as much about researching past decisions and figuring out why something was built a certain way, as it is about coding. I enjoy working with parts of Gutenberg that I have not worked on before, because there is so much to learn.
During this zoom call, we do a “standup” and let the rest of the team know what we are working on. After the call, I will either continue coding, if I am in the flow, or make lunch. If I have a meeting scheduled in the afternoon or evening, I will take a break until then. Otherwise, I will end my workday in the early afternoon the same way it started, by letting my colleagues know that I am checking out.
The checkout is a lie
I did write that I checkout and that I end my work day in the early afternoon. All this really means is that I end the focused coding work, and I close Slack. If there are notifications later during the day, I may still respond to them, depending on their complexity. Without this flexibility it would be difficult to work async over multiple time zones. WordPress is always on my mind.