Binate Thoughts

  • The season for tinkering

    Like many, the holidays are about taking stock, reflecting, and recharging. They are also often about learning new things and experimenting. This year, I took some time to do just that and found myself returning refreshed with several excellent projects brewing.

    Move fast and break my things.

    At the start of the break, I knew I wanted to do too much, which isn’t an uncommon theme for many. However, I knew the point was starting to do things and keep doing them. 

    If anyone explores one of my experiments or things I worked on over the holidays and finds a bug, I wouldn’t be surprised. That’s the point. I moved fast and broke my things. Brewing to polish and level takes time, so this was done as an experiment with my things. I will now be taking that time.

    A goal started

    I am not the most frequent resolution setter, but I have one this year, and it’s simply to try and make 50 things in a year. These can be big, but they will probably be small for the most part. From themes to plugins to non-WordPress things, this year will be about making for me. 

    I will write more on the why of this in another post, but the short version is that I am turning 50 this year and want to get back to my essence as a maker. So, I did that this holiday: I started making each day. I will log most of the journey here or through Composition Products.

    The making

    I am closing out the break, having made a few things. Most haven’t been launched or need fixing, but they will soon be. I plan on writing about each, as part of this is also about writing as I go. 

    Don’t you miss the days when we wrote about what we created? I sure do. This year’s side quest is to write more about what I am making and have a more frequent writing cadence

    Here is a list of what I have made, even if it’s got friendly bugs.

    • This site and several others of mine use a new theme base. This is in no way a complete theme, but it is a start and it got me blogging again.
    • I refreshed many of my own sites, including their content. I aligned them to reflect what I do more and surface my projects.
    • I created a new site for my photo-a-day project for this year, which I am doing again.
    • A block in a plugin that is a mode switcher: seen on this site and others I updated. 
    • A duotone and filter plugin for images.
    • A watermark plugin for image prototypes.

    Along with these, I sketched out several prototyped ideas that include:

    • A holding page plugin that uses templates.
    • A prototype of a tagging and group plugin for images.
    • A generative line art and shape plugin for backgrounds.
    • A background generator plugin for the site editor.
    • Site editor style selector plugin.
    • A classic theme-to-block theme convertor.

    The learning

    Along the way, I learned more about several areas and identified areas where I wanted to dive. Here are a few things I got to explore this time:

    • Creating blocks: appreciating how easily you can scaffold one.
    • Block themes: particularly noting how you can rapidly prototype with the create block theme plugin.
    • Fly.io: I wanted to learn something new for deploying.
    • React/Remix: A new stack that’s not tied to WordPress and with native CSS. I fell in love with the ease of composing and plan to write about this more.
    • Plugins: I spent a lot of time learning the guidelines and some nuances around plugins.
    • CSS/JS: I dipped my toes into a variety of new things in styling and scripting.

    I also learned a lot about other areas in preparation for the following things I want to do.

    The approach

    I took a few different paths along the way and also used tools. In general, my approach was to write down everything I wanted to make at the start and then not hold myself to any product roadmap for once and this once only. While my passion for them remains, I wanted to give myself a pure experimentation space to make in.

    Some notes from my approach:

    • I used Cursor along the way as a prototype or unblocker when I was using something new. For example, I explored a new project using Remix and React publishing to fly.io at one point. I wasn’t unfamiliar with this stack, so I got some support there.
    • I would pivot to another idea if I hit a block that took too long. I was brewing something with editor styling, and it just wouldn’t shift. I would have taken most of the holiday on this alone and got nothing else done. I will return to this idea, but it didn’t serve well for rapid ideation.
    • I pushed to a private repo on GitHub each day. I will make things public, but being private helped me.
    • I released my theme and other pieces early onto the sites as shown here. Bugs can be found in my things when I use them.

    Reflections

    Sometimes, you need to get a bit selfish to make it. I did this holiday. I didn’t think about the market or the reason for making it. I made it for myself in most cases. I also made it to learn—which often is a good reason to make in itself. Selfish-making isn’t always the right path at all, but it is something I’ve not done for a while, and I needed to get into my teashop and brew for a bit.

    Not shipping everything is also okay. I am very comfortable launching early on my own sites. For example, this theme is very minimal and will be something I grow into, but I happily am now using it across a number of sites. The point is I got it done, bugs or not. Bugs are friends you get to move projects forward with by fixing when in your own teashop.

    A reflection I’ll wrap up is to keep going. It is going to be tempting to get distracted by work in the best way and not make space to keep going with the momentum I gained this break. In order not to let all this good work go stagnant, it also needs refinement and release. So now the hard work happens. I will have a day a week where I continue this work. I have learnt by doing this that making gives me energy and a longing to continue.

    ,

  • Sponsored contribution reflections

    For the past six months I have been sponsored by Automattic for 2 days a week to focus on the default theme task force. First, I want to say thank you to everyone that supported and enabled this focus work.

    Stats

    When my sponsorship focus started the default theme queue had over 400 tickets and as of writing this there are 198 tickets. Whilst this isn’t just down to myself, it shows the importance of focus in this area.

    In this time I have brought to commit more tickets probably than ever in my history as a committer. I had to check but this also out paces in time phase one work I did on the editor. This shows how giving a contributor the ability to focus in one area can benefit the project and use them effectively.

    • Commits: 103
    • Updates: (comments, feedback and interactions on tickets) 965
    • Closed: 290

    It wasn’t just about tickets though. Monthly update posts were made to make/updates and also bi-weekly triage sessions run. A repo was also set up to explore co-ordinated approaches across tickets and a community theme experiment explored.

    For a more details see my last review.

    Reflections

    Stats are only number stories, but they are important to tell as a starting point. I have already shared some reflections but I am going today to give some more. Overall, having a focus was incredibly rewarding and whilst it is over, I am now looking to see what opportunity is next for a similar one. These reflections are around specifically sponsorship.

    Sponsoring is important

    I am currently self-sponsored, but I want to highlight how important that is. I still consider my own Five for the Future commitment as part of my work. However, having additional support would allow me to focus in ways that wouldn’t otherwise be possible. Every sponsor makes a difference. Thank you, Aaron Jorbin, for sponsoring me on GitHub. It allows contributors like me to continue thriving while working as committers.

    Focus is critical and tempting

    In the past few months, my focus has narrowed even more as I tackled the huge queue. If I continue my sponsorship in this area, it will be to address the longer-term issue of default themes. Only time will tell if I have prevented future fires.

    Support committers

    Many assume WordPress committers are sponsored, but this isn’t always true. I am not saying committers are the most important, every contribution counts. They can unblock and improve areas, and it’s valuable to retain their expertise within the project. Supporting existing committers can create opportunities for new contributors, with the added benefit of knowledge sharing through mentorship.

    Selling what you do is hard

    I find it hard to sell my work as a form of contribution, and I suspect others do too. Reflecting on my work, I realized how much I’ve overlooked in past interactions. It’s difficult to justify why you deserve sponsorship and effectively sell your work. This therefore often results in less sponsorship and we lose contributors that way.

    Next?

    I am looking to continue focusing, but I am open to where it is. I am no longer an outside sponsored contributor and welcome discussions, so please reach out. Specifically, I would love to do something similar, focusing for six months in another area. Here are some of my current ideas:

    • Admin-style sprint: a six-month focus. First, identify, triage and fix bugs in the existing CSS. Then, bring in new system work to the existing admin where can and updating without breaking.
    • Default Themes Task Force Part Two: The next phase could involve exploring a community theme reflecting past default theme styles and transitioning from classic to block tools for a seamless, user-friendly experience.
    • Component adoption: Sponsor me to adopt a component and do the same thing I did for default themes. This also extends to the editor, where I am also very open to jumping in as a focus again.
    • Documenting and making the design system visible: The design system is a powerful tool, and I am excited about its potential. The documentation could be better, but I am eager to focus on making all our hard work visible and truly showcasing the system’s capabilities.
    • Your idea: I am open to discussing any area you think I should focus on.

    I would love to talk more to anyone about these ideas or anything else around sponsoring my contribution. You can also sponsor me through GitHub. Beyond that, I would love to talk to anyone about these areas I am looking to focus on, I will be focusing on them one by one through my own work, this isn’t the end of my contribution. However, being sponsored speeds up the time I get to focus on them.

  • Prioritisation is challenging in Open Source

    Everything I write in this post comes from having been on many sides of projects. I have been the one lost, needing to learn how to prioritise, and the one looking to prioritise. Both are challenging to sit in, and simply knowing what to do is the eternal issue with a contribution.

    You can’t escape the need to be valued; it’s human. A contribution must feel that way, and the person giving it must also feel it. The fractures and emotions come pretty rightly if you work on something and discover it’s not required, either due to something else being worked on or simply because you didn’t have the proper context. That’s why many don’t want to make the first move; the fear of contribution rejection is a reality.

    The post that started these thoughts again.

    I want to acknowledge Rich Tabor’s post ‘WordPress & Iteration‘. In it, he discusses how iteration is “relentless improvement, not merely fixing what’s broken.” He also encourages deliberate thinking, which I completely agree with. However, I also recognise the complexity of that concept. Recognise how your perspective within the project and area you are working on may vary and how you can move deliberately in mental safety.

    This post isn’t a direct response to Rich’s; the conversation that inspired it came from it on ‘X’ about knowing when to prioritise.

    The responsibilities of wayfinding.

    I firmly believe in collaborative open source, but that doesn’t mean it shouldn’t have guidance. In projects, guidance typically comes from release leads and component maintainers who see the broader view and can offer that insight. The output within WordPress is in boards, posts, and other formats, depending on the area you contribute to. I also recognise this can and should be improved. Communicating wayfinding is one area we should iterate on.

    This isn’t dictating, though. What is needed is easy viewing and finding of the consensus direction—what is the next thing to work on and the release goals. Then, focus can be done. This helps those casually contributing and companies sponsoring contributors to fund in areas that need it.

    Measured passion and picking up trash.

    Passion is amazing. As far as WordPress goes, open source is still a product that needs measured passion to release. Passion is a drive, but measuring it sees results. We sometimes direct that passion collectively, seeing where someone has passion, supporting that for the project, and then coming together to release it. Your passion might sometimes be different from the passion that gets picked as the thing. That’s okay because projects ebb and flow.

    One of the most significant advice to new and existing contributors is to go on trash-pickup duty for a while. There are always tickets to clear, bugs to fix, low-hanging fruit to pick, patches to test, and things to commit. 

    Find a thing for you.

    Finding a sense of belonging in contribution is vital. It’s essential not just for longevity but also for your human needs. Once you feel at home in a project and flourish, I encourage finding a space you can work in and know. It doesn’t have to be significant. A small area of expertise is often significantly better than flying around a project trying to do everything. You will rapidly wear out if you try to do less, mainly at the start. Finding a niche, a place to belong, means you can achieve, get that contribution hit and ship. Rinse and repeat. You also get to make the project better.

    Learn to ask questions.

    This is hard. Knowing who to ask questions and reach out to is a privilege. However, many are very open to this across many channels. Ask if you need to know if something is a priority or if you think it should be. Find out the context. Understand the path. Learning when to ask questions and when not to is part of the work here. Another critical piece is learning to sit when there might not be an answer—often, that can be hard for initial contributors.

    We presume others know prioritisation.

    The ability to prioritise in open source often comes to later contributors through need and passed down survival advice. We can do better as a project. It needs to be baked in a little more, just enough process – not too much to stifle – so that good habits can be formed from the start for new contributors. We can only presume that some know how to build a product, prioritise tasks, or triage. We can pass the skills of the product on through contribution, and that’s a skill that will then benefit not just the core product but everyone creating it.

    The confidence of right.

    There is confidence in knowing what is right and what should be iterated or not. It often involves a deeper knowledge of space. It’s amazing if someone has it, but it is not something everyone has. It is, however, something that can be shared and nurtured in others. It is a gift to grow and flourish throughout the project.

    There is also a confidence of personality often gained through being longer in a project, but that is harder to tackle, and we often don’t think about it when we approach things. Some even longer-term contributors are still cautious by nature due to their personalities – humans are different. We can ease this a bit through gentle, supportive processes and realising that not everyone has the spirit, passion, confidence, view, or knowledge of what is the most impactful.

    Where now?

    One of the critical things I think needs to be added right now from this project isn’t that everyone needs to work on the same thing but that there are clearer paths. For example, it’s easy if you are a full-time contributor for many years to presume someone might have knowledge they don’t when they only contribute for an hour a day once a month. Similarly, the contributor who only comes every other month can expect their process to differ from the one used. Having clarity around things, and I hate to say it, documenting this helps. Each team will do this differently, but it needs to happen more and help those joining.

    There is never a right or wrong answer in open source prioritisation, but decisions must be made—that’s what a release is. One thing you can do is have a passion project brewing. However, as you grow in your contribution, it is vital to know and be supported in your skills to focus on the right tasks. A contributor needs to feel the value of their contribution because they are human. If you want a summary, the answer is to follow your measured passion, check it’s aligned, and always pick up the trash on the floor.

  • Focusing contribution on the Default Theme Task Force

    Back in December last year, there was a proposal for a task force focusing on the default themes. This came from discussions at the Community Summit titled ‘“Improving the maintenance of older default themes’. This was a great discussion that went in many directions, the key point was in order to progress we need to fix what we have.

    The idea is summed up in the proposal post as the following:

    • Triage the list of open tickets for the Bundled Theme component.
    • Address bugs in a future-proof way.
    • Individually evaluate enhancements and feature requests, closing any that are no longer relevant or not supportive of project priorities.

    This comes from discussions at the Community summit last year and needs doing before any changes to processes or even which might become block based. As Jonathan says in the post:

    “Once this ticket list is under control, further discussion can be had around potential tooling changes (GitHub vs SVN), frameworks or methodologies that can be implemented to make maintenance easier, etc.”

    It’s essential theme work, there are quite a few issues to go through one by one – the point is though to methodically go through each theme and clear the backlog. Default themes are critical for the project, many learn how to theme through them and also they are the starting point for many work.

    Themes hold a strong place in my heart, having been a thread and drive throughout my journey in WordPress. I have been part of several default themes. For me being able to be part of this task force and work on it was something I was passionate about. It’s also something I can contribute to as a committer and someone that has worked on many of the default themes previously.

    I am pleased to announce that with an initial six month contract, I am going to be a sponsored contributor for 2 days a week, thanks to Automattic on this task force. My primary goal will be to close as many tickets as can, theme by theme.

    Thank you for those that helped co-ordinate this sponsorship, getting sponsored enables contributors like me to focus on projects like this and means so much to each of us when it happens. I am excited to focus on this and begin the work at the start of March. Let’s do this and work through that backlog!