• 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!


©2024 crafted on WordPress, made by logicalbinary.