The Impact of A Contribution to Wagtail

Hi, I will be talking on the impact of a contribution to Wagtail. Now notice the to Wagtail part is in parentheses and That's because in the world of open source, a lot of concepts generally spill over from organization to organization. And in as much as this presentation is going to revolve around the WagTil CMS a lot of the concepts here spill over to other open source organizations. So with that out of the way, let's get to introductions. I'm Mizu, but you can call me Mizu or Mizu, both of them work. I'm a web developer and very active open source contributor.

And in 2024 and 2025, I was a Google Summer of Code contributor to the WACTL CMS on an accessibility project in 2024, which was the um creation of the image block amongst other things and the content security policy compatibility project which was in 2025 currently I'm a session five Djangonaut working on the Django debug tool bar, and as an icebreaker, I like cake. So, what is a contribution? Any action whatsoever that improves an open open source project is a contribution. So anyway, any bit of efforts that um an individual or a group of individuals do

to make an open Source project is a contribution to that project in itself. Now, there are several types of contributions, only few of which are known. Now, mind you, this list is not exhaustive and it It's not in any way in order of preference or importance. These are all valid ways to contribute. You could contribute by raising issues, by raising pull requests, by participating in discussions by donating translating triaging issues leaving reviews on pull requests um participating in polls surveys feedback platforms contributing to dogs being a part of the um teams for instance the wagtail

has had accessibility teams has had ui teams so being a part of that team is in a itself a contribution. Helping other contributors is also another way to contribute. And contributions to community maintained packages are very valuable. contributing as well. I will explain more about each of these in the coming sessions of this slide. So but this is just to put it out there on the types of contributions that we have. Now the importance myth. There is this really common misconception that certain types of contributions aren't so helpful or need needed and therefore best lots um done. That is a myth. It's actually very factually incorrect

and I'm here to show you just how incorrect that Is and what's worse is that these misconceptions often revolve around contributions that are not directly code related or that may be some form of dog fixes or that may be strictly obedient. opinion based and those misconceptions can be very harmful to the lifespan of any open source project. But yes, this is a myth I wanted to dispel. Now let's start with dogs. And to start with dogs, we need like a rough um timeline of certain dog related things that have happened In the Wagtail CMS. So Wagtail first shipped in 2015 and when it shipped there was some form of documentation in existence.

Somewhere around 2021. Sphinx configured for Markdown supports. Also later in 2021, Wagdeo created its own Sphinx team and that got added. So the thing with Sphinx is it allows you Have your own custom themes that you can use on your project so it's very flexible. And sometime around 2021, the Wagtail Sphinx theme was added. Now Another feature or timeline, timeline-based activity that happened in 2022 would be the documentation markdown parameter. So I got changed from Recoma Mark to MyST. Now these are just like to give you a backbone of

the documentation stuff, the infrastructure or like the skeleton that allowed for what later became the official wagtail documentation. So this is what the wagtail docs looked like sometime around 2015 2016 in the earliest versions of Wagtail and this is what it looks like now Yes, it's definitely more than the change in a theme. There is so much more rich content. The documentation contains a lot more helpful content, and I assure you I assure you, this was not all done by the maintainers, it was done by contributors like you and I.

So I ran a GitHub CLI script. a couple of scripts to get some data and I found out that between the time of Wactails released till now there have been at least 330 six unique contributors to Wagtail on the topic label of documentation. So that means if you go to the Wagtail repository and you narrow it down to pull requests and you filter by the label documentation. If you bother to count, you'll count at least 336 need contributors to Wagtail. Mind you, this is not including the Wagtail maintainers or the core team.

So this is part of what made the huge difference between this and this. So now it's not just about the pull requests. Certain things have come up as discussion item items that were brought to the notice of the maintainers and the core team on things that could be done better in the work of documentation. And And the Wagtail Sphinx theme itself, which has a separate ripple, making it a community-maintained package of Wagtail, has also had contributions to it for the fullest of contributions you could for sure check out the repo and of course for every documentation addition or removal that was made there are people that reviewed these this goes to show that Even a tiny dog

fix can make so much of a difference in getting one, getting the documentation for an open source project. from point A to point B. Now here's a spotlight on something in the docs. Initially in the Wagtail, the earlier um wagtail docs documentations there was no tutorial but after a couple of issues and discussions on how things could be made easier for new contributors Wak til decided to try to get that fixed. That led to a Google season of doc efforts in 2023 and this project was beheaded by a contributor. called Damilola and the outcome was

Wagtail having a dedicated tutorial section in its documentation. Now this is one of the several cases of non-maintainers and just regular contributors like you and I playing a huge part in the subject. success of an open source project. So up next issues. Issues are a very good way of highlighting bugs, suggesting improvements, and setting up the basis. for conversations. So let's face it, you're a contributor or you want to contribute to an open source organization, the first place you're most likely to go is the organization's repository and you would most likely go through the issues there and try to find a fixed front issue

or try to filter by a label that resonates with you so that you could try to make a fix for that. Regardless of what route you go, chances are the issue section is where you will likely find yourself as a new contributor. Trying to get your hands dirty. They're a primary gateway through which contributors get a chance to contribute. Now, there is a common misconception that raising an issue Is not as valid a contribution as raising a fix for an issue, which is not true. So here are some examples of some really loved features have come into Wagtail and how they started out as issues from people in the community.

Multilingual support for Wagtail as far back as 20 2014 was an issue that was raised by a contributor who eventually raised the fix for that. Stream field editing interface performance issues. So what happened was in 2016 there was was an issue that a contributor raised about how the stream field interface lagged when there was a certain threshold that it encountered. Now that issue led to a rebuild of the Wagtail Streamfield and the inline panel UIS, which was something that also happened around the time of Wackdale's first hatch, which was a it was a fundraising campaign of some sorts to get some features into Wackdale

based off of the supports that Would come in during that campaign. Now, segregated multi-site supports also came up as an issue by a contributor in 2018. The auto-collapsing stream field blocks 2021 and the CSP compatibility issues, which I left for last because I'm this this this is a particularly um personal um encounter with Waqdew and I'll talk more more on that. So but all of these go to show that just even raising an issue of any sort is a valuable contribution to Wakde. because sometimes the things that could come off the um trying to look into an issue could be essential parts of

a system or a redesign or some feature fix or functionality addition that would eventually come up to the CMS. Now here's a spotlight The issue, which is the CSP issue. The CSP issue is actually the project I worked on from my Google Summer of Code 2025. But as you can see, This issue was raised in 2015, which was 10 years ago. Now, this issue has been responsible for a lot of design changes and tweaks that have happened year in year out in the Wagtail um repository now here is what that issue eventually bubbled up to this is the project idea for the Google Summer of Code 2025 project that I worked on.

So again this is a classic case of an issue raised by a contributor becoming a feature that was added later on in one day. The CSP um compatibility is not fully completed yet. but it just needs a few more pushes and it will be there. So now service and feedback forms. These are like the easiest ways to get um feedback or comments from the wider community at large and certain developments that have happened in the Wagtail CMS have come as a result, a direct result of the information retrieved from these surveys and feedback opportunities from the um headless surveys to the deployment surveys to even the work

in discussion page where active where active and ongoing discussions are um happening about things that could be done better in WACD and of course let's not forget the RFC section. So RFC means request for comments. For open source organizations, before major changes are introduced, more often than not, um the maintainers or the core teams or the administrators like to get community feedback so they want a place or a platform for people to read about some of the stuff that uh members are proposing formally to the open source organization, get eyes on it, get critiques on it, and eventually decide on a way forward

As to whether or not to embark on that particular feature. So RCs are very essential and they form what will be the back backbone of a lot of open source projects. Now here are some of the um discussions that have shaped Wagtail Way or the other. So these two are actually related. One is a comment on the discussion topic, while the other is the discussion topic itself. So sometime in 2017 There were issues or like there were complaints on the architectural depth of the UI in Wagtail. It led to a series of discussions that happened and some Sometime around 2022, there was a comment on a lightweight

front-end framework investigation. This was essentially what gave birth to why usage of the stimulus. js framework. Now if you don't know stimulus, I recommend you check it out. But if you do know the stimulus JS framework and you encounter the wagtail source code you would realize that the stimulus framework is almost at the core of what a lot of things in the UI do so That is a very classic case of a discussion leading to something that ended up being one of the most widely used parts of the work. code base and here is the RFC that came up as a result of the discussion for the

conversation on the UI architecture debt now translations when wactil released the only supported version of wactil at the time was the English language but um currently in 2025 as at the time of my reading this or as at the time of my presenting this um WACTEOs fully supports or rather has very strong support for over 15 languages Now, 15 languages is more than the number of languages that are in the core team or like that the maintainers know. So these extra languages definitely came from somewhere. It came from contributors, much like you and I. Now how does Wagtail

get translations from contributors? contributors. Well Wagtail uses the Transiffects tool and Transiffex integration was added in 2014. So for at least 11 years Wagtail has enabled contributors contribute to more languages in the Wagtail CMS. And while it might not seem like a big deal, while it might seem like oh just translating one word or one sentence or doing a typo fix, these things eventually bubble up. They cause a domino effect and the reward is something that the whole community who gets to reap. Now this is a picture of some of the languages that Wagtail supports and their levels of support for these same languages

The fun part about this is that this is just I think a third of what is actually on the page. So there is ongoing efforts for a lot more languages than you can currently see here. And you could definitely be one of the contributors if you if you wanted to, which I do recommend you do if you can. So this again goes to show that the efforts of contributors contributors all matter because I mean if not for somewhere somebody somewhere out there Makil who knows may not have had a um Catalan translation So, yes. Now discussions. Discussions are also a very helpful addition. A very nice way to contribute. So

if you look at the slide you would see that there are three um discussion topics that are still uh the links are there while the other two are just the um ticket numbers. Well the other two are actually done. They started out as discussions and made it into features or improvements in Wacktail. Like the supports for RTL RTL means um right to left. So So languages where the writing typically starts from the right then moves to the left. This was a feature that was really anticipated that in Wagtin and it allowed the support for some RTL languages, it did start out as a discussion. Some WACT admin dashboard enhanced we've

started out as discussions and right now in the um discussion section on work too we have um topics on adding activity pop support um the django mongo db backend public preview and some more discussions on the segregated multi-site support. And these are discussions that are open to everybody to continue. because at this point in time we've probably seen it in a number of instances where just one effort from a contributor, no matter how seemingly small, could start a domino effect and lead to something much larger than a contributor would have normally expected. So here is a spotlight on discussions now for Wagtail

7. 0 one of the most talked about features was the introduction of the auto save functionality. Now it didn't start out as an intention to just have autosave. There were some underlying issues that were raised several years ago And in 2021, the Autosafe issue, the official reference point for the Autosafe functionality, was created as a ticket and this feature or this issue would four years down the line end up being one of the most anticipated and uh one of the best liked features of the Wagtail release.

So this is yet another demonstration of where a country Contributor does something that they could not possibly imagine being a huge feature request, but just do it because well they're trying to contribute and make the CMS better. Now pull requests. This is about the it's the easiest. It doesn't need so much in terms of explanation. I mean a pull request that gets merged into the Wagtail code base is a contribution. You've essentially contributed a piece of the Wagtail source code and whoever uses Wagtail will one way or the other interface with something you've contributed a line of code to

and that is a comp Completely valid, valid contribution, which would always be appreciated. This is, I think, one of the most common ways for contributions to be done. in the Wagtail project and so far we've had over 860 unique people open at least one pull request which has led to thousands of pull requests being generated. Donations, well donations are essentially how some features get introduced into Agdeal. So when large organizations or small ones use or require particular features they could donate and have um the Wagtail team work on these features.

These are some of the examples that have happened like the page editor with google or wactel localized with Mozilla DIT and Twilio um to check out more of these and to find out more of what these donations donations I've listed have been you could head over to the whackto. org sponsor page and definitely read up on that but donations are a way of helping because let's face it The bulk of open source work is volunteer work and it's people giving you a piece of their time, their effort, their energy, and their knowledge to make something better. So a lot of times the the donations you make go a long way in terms of support for both the maintainers of any project or people who are willing to contribute

would appreciate um some monetization for the time they spend working on these features so donations are definitely a welcome way to contribute to any organization In fact, they are one of the most helpful ways. Up next, triage and reviews. So triages are really convenient for maintainers. I can't not state this enough sometimes it's particularly relieving when you are looking for what to contribute to or where you could um put some effort And on the issue section, you'd see labels that have carefully been arranged for you to look into. This is it's it's convenient. They are not as commonplace, but they are thoroughly appreciated and triages

serve as a confirmation of issues because if an issue can be triaged it means it can be replicated and if it can be replicated It means a solution can very well be found for it, even if this the solution may not be apparent. So um likewise reviews, if they are pull requests that are up there you could review give your nuggets there might be better ways you have or cleaner more efficient processes the community needs you to help do this these things because when you do them to you you might not feel like the person that put up the issue you might not feel like the person that um raised the pull request you might not feel feel like the person that did the merge but

ultimately you have a hand in just how efficient the code that was merged gets to be because when you review things you help make the software a whole lot better in general now this is yet again the um wax tail stimulation Now notice how there are 145 comments on the conversation. This I think is one of the most talked about um RFCs or rather one of the most commented on RFCs and all the comments one way or the other helped to refine the approaches that were eventually used into making the stimuli a possibility in the Wagtail code base.

So every contribution counts even if it's down to a comment on a request for comment. Now helping contributors and this is where I'm going to tell a little bit of a story. So I've been contributing to the Wagtail CMS Pro For roughly two years, and I won't lie, the reason I've been here this long is largely because I found help every step of the way. When I Contributed to WACTL the first time. I had not concluded it would be WACTL. There were a couple of organizations I was trying to contribute to at the time. And I all sent, I sent all of their messages. I introduced myself on their community channels. I was eager, willing to get started, willing to get my hands dirty on something, but it wasn't

where I got so much help. Like there were people who welcomed me, who gave me tips on what to look out for, who helped me find issues that were beginner friendly. and I dare say that those people are very essential to my wagtail story. Like I cannot measure the impact of the help they rendered But I can tell you for a fact that those efforts they made ended up with me being a contributor to the Wagdew CMS for Google Summer of Code twice. It allowed me also assist other contributors. It gave me a much needed confidence boost and it gave me the morale to go on and contribute to Django itself, which is how I found

myself as a Django naut. So and by mind you Django is the framework that Wagtail is built off of. So receiving kindness is definitely receiving help. Rather is definitely a kindness that every contributor will forever be grateful for. So sometimes even just helping out that person that wants to help is in itself a contribution to Actil because it cannot be stressed just how important it is to help people. At the end of the day, that's what the core of open source is all about. helping people so next steps contribute join the community slack wactil. org slash slack

Get started on something, talk to people within the community, just help out wherever you can. If it's a contribution, like a translation, if it's a pull request. If it's an issue, it's a feature request. If all you can do really is just look at stuff, then please do look at stuff, give your feedback, give your opinions, just contribute. it helps make the community better and in the ten years since Wagtail's um inception, this is how good it has been so far. Now imagine all the good things that could come of having even more contributors helping out and looking out for the community. So if you do want to reach me you could reach me on LinkedIn at um Chemizo

Akujubi or uh X formerly known as Twitter on C N E underscore T-I-O-N and I hope it wasn't so easy to tell but this was my first Ever talk and thank you all for attending. I genuinely appreciate. Catch you next time. Bye.