Community Spotlight: LB
Meet our Stimulus expert and a champion for new contributors
1. Tell us a bit about yourself. How did you get interested in contributing to open source?
I'm LB, I live in the sunny Brisbane, Australia. I'm married to an amazing wife and have one four-year-old boy. We love to travel. This month marks ten years since Bec and I first traveled overseas (to the United States). Since then, we've visited about 20 countries and even did a year of remote work and travel in 2017. Hopefully, I'll get to increase that number a bit next year.
It was during our travel year that I made my first contribution to Wagtail, fixing a small JavaScript template issue.
My start in open source was much earlier with a bit of early involvement in the MeteorJS community. I contributed mostly small docs fixes and a wrapper package for that ecosystem. I've always loved the core philosophy of open source and, of course, the free software movement. I like that people from all walks of life and skill-sets take part in a community effort to build something bigger than they could build on their own.
2. What drew you to the Wagtail CMS project? How did you get involved?
As noted above, I had made some early contributions to fix a few pain points I encountered when adopting Wagtail for an intranet project I was working on. We had evaluated a range of CMS, Wiki and intranet solutions that were open source and software-as-a-service (SaaS). The team that worked in the community I was consulting for already worked with Python and PHP, so that helped narrow down some options.
We tried out a proof-of-concept on a few different platforms and found Wagtail to be the best solution. It was built on Django, had a robust web framework with lots of support, and it had an incredible UI (for an open source project).
The first time I worked with making a custom model editable (non-page), it was such a delight. I remember being astounded with how easy it was to make the full suite of editing, managing tree-based content, making menus, and setting up permissions with barely more than a model definition.
I ended up writing a few blog posts about how to do some things with Wagtail. Including the post Building a Configurable Taxonomy in Wagtail, which is still my most popular post to this day. I really should rewrite it with the new Snippets / Viewsets approach at some point.
After a few more contributions, I got an email from someone named Tom Dyson at a company called Torchbox. I'd never heard of either name initially, but found out that Wagtail was created by Torchbox and Tom was the co-founder and a core part of how Wagtail came to be.
We lined up a call and, due to timezone issues, it was about 10:00 PM local time for me in a dimly lit AirBNB in some random part of Cambodia. I had to have my phone on torch mode for my camera to not look too awful. We spoke, and he invited me to join the core team. I was quite taken aback. A week or so later, I had merge permissions on the Wagtail repo and I've been a part of the team since then.
3. Do you remember the first version of Wagtail you worked with? If so, what version was it? How much has Wagtail changed since then?
Probably around 1.8 (LTS). I remember working with the company I was consulting for and making some decisions on adoption based on the 1.8 features that were coming through.
An immense amount of things have changed since then. Some of my favorite parts have been the Workflow system, unified handling of history for models, Bulk Actions and, of course, the move away from ModelAdmin.
The UI, UX and accessibility support has been improved in leaps and bounds. Wagtail stands out even more so as a really polished UI experience. There's always more to do, but the Google sponsorship last year (2022) enabled some great improvements.
4. You submitted your very first Request For Comments (RFC) proposal last year with Wagtail. Did that feel like a career milestone for you?
Yes, well, that was quite a journey. I remember being on a call with Thibaud in one of our UI team meetings late 2021(ish). No one else could join the meeting and I was looking at some jQuery code with him and asking what I should do about rewriting parts of it. He then explained that we (the Wagtail project) should think a bit more strategically. Instead of adding bespoke jQuery with bespoke JavaScript, he suggested we should research libraries, approaches and look at other past initiatives plus research that had been done.
Oh gosh, that started a significantly large journey for me down a rabbit hole with more surprises than a cat with only a smile. After digging into and trying out multiple libraries, I convinced myself that we should use either React (what I use in my day job) or Alpine.js (a popular HTML attributes approach for JavaScript integration).
Then came the unexpected requirements. Supporting Content Security Policy (CSP) was a non-negotiable, and we needed the ability to write in TypeScript in our core code but not need any of the build tooling for people who develop with Wagtail. We needed to use a small amount of JS and have a thin-but-powerful API for almost all our existing use cases. No one wants to use React while everyone wants to to be able to at least have React as an option. We were also encouraged to only use vanilla JavaScript (no libraries) but avoid boilerplates for common task. We also had to think about name spacing and avoiding conflicts with other similar library usage that may come about. There were definitely many expectations from the community that seemed to be non-compatible with core Wagtail constraints.
But the journey was incredible. So many opinions and constraints really helped us push through with a solution that I feel was better than anything I could have created on my own. Many of the main ideas that eventually ended up in the RFC were community-contributed, including many people who weren't on the core team. It was a lot of work, time-wise and mentally, but I loved it so much.
I do wish the process was faster and the PR reviews for the migration happened faster, of course. However, the goal here is an intentionally longer process, to help the community and core team go on the journey also. Good decisions take time and seeing fruit from those decisions takes time.
In terms of career, it's been so great to have been forced to learn ways of thinking about JavaScript/front-end outside of my React bubble. Before this process, I barely knew about Web Components, the simplicity and power of data attributes, browser APIs like formData, MutationObsevers and IntersectionObservers. I had little-to-no understanding of the nuances of Promise, SetTimout and Microtask timing, and so much more. I can honestly say that several critical improvements in how we implement things in my work projects can be attributed to the time I spent on this RFC.
5. What did you learn from the RFC process and what tips would you give other developers who are thinking of contributing an RFC proposal to their favorite project?
It's important to read a lot of other RFCs, I read through probably the last 5-10 of the Wagtail ones. I also read some Python (PEP) structures and one of the Rust RFCs for inspiration on how to write these and how to balance between detail and summary information.
I also had to decide that I was the one who was going to own the process end-to-end. Whether or not it got approved, I originally didn't think Stimulus was the right way. But with research and testing, I found it to be the best option at the time, with the reality check that there is no perfect solution to any problem. Others in the core team were behind it, but someone still had to champion it as the only solution, even if that meant I could be wrong. Who knows, maybe in the future myself or someone else will write a new RFC on why Stimulus is holding us back and new "thing" is the right way forward. The point is, the RFC is a community process but still needs to be driven by someone. That ownership is scary. No one likes to be wrong, especially in public. However, none of us are ever always right, we're lucky if we are right more than 51% of the time.
Despite all of that, if you feel there is a solid improvement and have discussed it in other informal ways (discussions, issues, maybe a POC package), it's 100% worth doing an RFC. Even if you get knocked back, remember that you and the community can learn from each other and the process. However, it may be good to start with an issue or discussion in Wagtail's repo first.
6. You've been a mentor for one of our open-source internships and you've also regularly help us orient new contributors. Where does your enthusiasm for helping new folks come from?
Being a mentor was great. It was hard but also so rewarding. The best part was that my employer gave me time out of my week for a period to do the mentoring. I still had to do lots outside of hours, but I'm very thankful that my manager was willing to take a risk with me doing that. I wrote a bit more about my experience in a blog post.
One of my favorite documentation pages I have worked on is our first contributors guide. It bundles up many of the repeat questions we see for new contributors. It takes a developer on a journey from just having their laptop in front of them to having a contribution merged. Of course, there are many folks who never read it and still run into the same problems, but at least we have somewhere to point them to now!
As for why I'm up for trying to help, I remember what it's like to learn new things and feel so clueless. I remember not having any idea about Git and seeing it as a cloud of confusion. I remember writing a PR and accidentally committing all the temporary test assets or all of Node modules and someone kindly pointing out my mistake. Others have taken the time to not judge me for my accidents and helped point me in the direction of learning how to do things I didn't understand.
I hope, in a small way, I can help others learn something new and feel the success of a small win. Even if they never contribute to Wagtail again, I would like others to say it was a good community, and that they were challenged but learned something new. Empathy and a bit of grace for others can go a long way in making your life and someone else's life a bit better.
7. You spend a lot of time working on the Wagtail's front-end features, including documenting many of the things devs can now do with Stimulus. What are some useful front-end features that you wish Wagtail developers would use more?
I really do think that Django's widget attrs and Wagtail's Panel attrs support combined with Stimulus for a JS customization creates a powerful way to do complex things simply.
I also love that Stimulus not only promotes but is built on using the browser's DOM events system. I'm hopeful that we will document some more events in the future, when they're more stable. But what can be done with a simple dispatchEvent or addEventListener will set us up for a large amount of customizable behavior with very little maintenance overhead.
I'd encourage everyone to first though, always look at what can be done at the Python/Django level first. I answered a question this week on Slack in which they had a very complex JS change that was modifying a button. However, we actually already had a Wagtail hook that could have done 90% of the change they wanted to make.
While we can't make everything work with just Python/Django only, we are trying to consider this always as the first way to build on Wagtail. If that blocks you, passing some attrs / adding some data attributes to a template should be able to get you closer to your goal.
Finally, writing JavaScript should be easy to do and developers should not have to think too much about whether a field is in an InlinePanel, model or StreamField when making their widget do something fancy.
I should call out also that JavaScript developers often reach for JS when in fact all they need is CSS. We've done a lot to make it easier to "select" the right elements with unique, name-spaced classes. We've also actually pulled out large chunks of custom JavaScript and replaced it with simpler, more accessible CSS/HTML solutions while migrating to Stimulus.
But, if you need to make something work on the client, we hope that Stimulus gives you the freedom to do anything you need without having to use a bespoke tool and write a lot of the common instantiation code yourself.
This Week in Wagtail
A weeklyish newsletter with Wagtail tips, news, and more.
