DEV Community: Chiemezuo

My Google Summer of Code (GSoC) 2025 in View

Chiemezuo — Fri, 29 Aug 2025 19:24:48 +0000

On May 8, 2025, I received an email stating that my proposal, titled "Content Security Policy Compatibility," for the Wagtail CMS had been accepted. It was an exciting moment, and 3 months later, I'm here to share how things went, along with links to all of the work that was done.

Introduction

I'll start with some context to understand the GSoC project topic, the state of things before the project, the state of things after changes from the project are merged, as well as a scope on what can be done in the future.

First of all, what is CSP? To quote the Mozilla documentation: "CSP is a feature that helps to prevent or minimize the risk of certain types of security threats. If that's confusing, here's a reference to an explanation of CSP from an article I wrote during my project.

The Starting Point

The foundation of this project was laid in 2015 via a GitHub issue. Some fixes and discussions went on from that issue, and a few years later, another issue was created as a more up-to-date listing of Wagtail components that triggered strict CSP violations. Now, in 2025, an even more recent CSP audit was conducted.

All of this means that at the time of commencement of my project, the Wagtail CMS had a handful of issues holding it back from supporting strict CSP, which were summarized in this comment. This made planning very straightforward, so my mentor Sage and I drafted a GitHub project board that became the reference guide for my GSoC 2025.

Finally, making CSP improvements would be nothing without a place to test and document them. The BakeryDemo and Wagtail.org websites were ideal for having a template developers could walk through, and a production site with CSP running.

What I did

The project was divided into sprints of focused tasks, with the easier fixes being addressed first, to make room for tasks that depended on other members of the community. There was a pull request for refactoring the HTML and CSS across the CMS to remove the usage of inline style-src. My mentor and I reviewed this and quickly merged. This was the first merge of my project. Shortly after, I sent in another Pull Request (PR) for inline style-src, for issues resulting from JavaScript code.

After style-src, the logical progression was to try to tackle script-src issues in the codebase. However, the culprit component causing these problems was a part of a larger system that required a refactor: Inline Panels. The first part of the refactor was already in the works by LB and some of the Wagtail Core team members. While that was in review, I proceeded to fix an issue with a client-facing aspect: background positioning. This depended on some feedback from the core team.

The primary target of the next sprint was inline panel refactoring. There was a PR already in place for this, but it was incomplete and needed a review of the intended implementation. The contributor allowed me to continue working on it, and I did that in a separate branch/PR. Work on the new branch went on asynchronously and is still in the works at the time of writing this. The async nature of it allowed me to take on some other tasks in the sprint period, most notably of which was setting up a local version of the Draftail editor, which is Wagtail's editing interface. The editor itself had some dynamic style generation, which wasn't CSP-friendly. I started work on it, but didn't have a clear sense of direction, and came up with a draft of what could work. My mentor and I agreed on having the draft PR as a reference, and adding it to the backlog to focus on things where there was already a clearer direction.

The following sprint fell during the time of Wagtail's code freeze, which is the span of time just before a new Wagtail release, where code changes do not get merged until after the release. For that Sprint, I focused on reviewing existing and pending CSP-related issues and tasks. It was a period of research and exploration of some options for potential CSP issues. During this period, I also worked on a way to prevent new CSP issues from creeping in in the future. I had the idea of a "code checker", and my mentor mentioned writing a Semgrep rule to perform the checks. I wrote the rules in this PR, and made a note to plan towards moving the JavaScript/TypeScript checks to Wagtail's ESLint repo. The last activity of this sprint was checking that SVGs, when uploaded, would not violate CSP directives when they contained inline styles. This investigation was done, and SVGs didn't get in the way.

With these out of the way, the next steps (in no specific order) were migrating the file title generation logic on image and document upload to use a Stimulus approach, testing Wagtail with Django 6.0's in-built CSP package, establishing a CSP baseline with Django 6.0 on both the BakeryDemo and the Wagtail.org, documenting my findings, pushing my work to more public lights for scrutiny and feedback, investigating deeper into the codebase with a focus on dynamic scripts, and putting finishing touches to existing PRs.

The Current State

At the time of writing this, some of the work I did has been merged, and some is still under review. There has been progress in the state of Wagtail's strict CSP compatibility, and there will soon be another CSP audit when the rest of the unmerged/unreviewed changes are finalized and merged. The GSoC project, along with the addition of CSP to the Wagtail roadmap, has also garnered some interest in seeing the CSP goal achieved.

What's left to do

At the time of writing this, the pending parts from the GSoC project board are:

Fixing the Draftail editor's dynamic styles.
Fixing some dynamically injected JavaScript code from within Python in the Wagtail code.
Giving a full report on my CSP test findings using the upcoming Django 6.0 in both the BakeryDemo and Wagtail.org projects.
Finalizing/merging the pending PRs already linked in this blog post.

Thoughts

It's been magical watching and being a part of how a 10-year-old GitHub issue might finally be closed. This is one of those moments I am truly grateful for, that only open-source software can give. The last 3 months have been full of nothing but excitement, learning, and collaboration.

I'm grateful to my mentors Sage & Thibaud, LB, and the Wagtail community as a whole for being such great teachers and collaborators. They made my GSoC experience amazing.

Finally, big thanks to Google for giving me a life-changing experience.

Till next time!

Cheers.🥂

Configuring CSP: A Test For Django 6.0

Chiemezuo — Fri, 29 Aug 2025 15:03:42 +0000

Right away, some things could potentially be confusing about the title of this blog post. What is CSP? How does it relate to Django? Why Django 6.0?
You would be fair to ask these questions, especially because at the time of writing this, the current version of Django is 5.2.5. Let's get these questions answered.

What is CSP?

CSP is an acronym that stands for "Content Security Policy". Just as the name implies, it has a lot to do with "security", and this is achieved by placing restrictions (or policies) on the content from websites. Over the years, browsers have evolved to be incredibly powerful, while making sure that content accessed on one website cannot run malicious instructions in the context of another website tab or another part of the computer altogether. However, this leaves a small window of opportunity for the said malicious instructions: "the context of the same website itself". That might sound vague, but if malicious code could somehow get served from whatever website you're on, then it can be executed in the context you're in. An example of this would be if there were a console.log statement in the resulting HTML of a website, an inspection of the dev tools console would reveal it. Here's where things get interesting:

Something far more harmful than console.log scripts could be done outside your immediate view.
On some websites, especially content-heavy ones without data sanitization, these scripts could just about be added by anybody.
The scripts don't even have to appear to be on your website (as in the case of "clickjacking").

How does this relate to Django?

Django is one of the most used web frameworks on the planet, and can be a conduit for the types of attacks that CSP helps prevent: clickjacking and cross-site scripting (XSS). CSP also helps with making sure Django loads your site's pages in HTTPS.
In summary, CSP is tool-agnostic; Django developers would benefit from a good grasp of it.

Why Django 6.0?

There has been existing tooling to test and enforce CSP in Django. The most recognizable of those has been the django-csp package developed by a team at Mozilla. It is available on PyPI and does an excellent job.
You might still be wondering how this answers the question: "Why Django 6.0?" In May 2024, a conversation began to explore the possibility of adding CSP support to Django. The idea was to create something better, with no need for another package installation, and with good out-of-the-box support. That conversation morphed into a Pull Request that has since been merged and will be coming with the release of Django 6.0, scheduled for December 2025 at the time of writing.
Thankfully, you can get to testing it right away, and that is what the rest of this blog post will show you how to do.

Setting up Django 6.0

To fully understand the setups I used, an understanding of my motivation for this Django 6.0 test run would be helpful. All of this CSP work was geared towards my Google Summer of Code (GSoC) 2025 project with Wagtail. The project was about fixing the gaps and ensuring strict CSP support for Wagtail.
In a sense, everything I did revolved around the Wagtail CMS, and how sites built with it interfaced with Django.

I tested with two different open-source Wagtail websites:

The BakeryDemo
The official marketing website of Wagtail

The Bakery Demo project uses pip from Python for package management, and the Wagtail dot org website uses Poetry. The differences in connecting both were very subtle, with the bakery demo being the easier of the two. The overarching requirement was that you would have cloned the most recent version of Django from its GitHub repository.
For the Bakery Demo, you would need a virtual environment and an installation of Django pointing to your local editable version via pip install -e /path/to/django. This virtual environment would contain your Django, editable version of Wagtail, and Bakery Demo website.
For a poetry-based installation, modifying the project's pyproject.toml to point to a locally editable version of Django (or mounted volume of it, as in a potential case of containerization)

Note: Keep in mind that you may need to upgrade some dependencies depending on the support hitherto. This may not be the case for most websites you may want to test this with.

Testing a Wagtail/Django site with CSP.

At the time of writing, the docs for using the built-in CSP tool proved very useful. You could choose to set up CSP to outrightly block unsupported content using the Content-Security-Policy header in your settings, or you could set it up to report CSP violations (either on the console or via a dedicated URL) with Content-Security-Policy-Report-Only.
The question of how to write the logic is something that comes with a bit of flexibility. Ultimately, the built-in CSP support in Django reads from your settings.py file (which can sometimes be split into base.py, dev.py, and prod.py. A setting like the following would get you on your way to Django's CSP usage:

from django.utils.csp import CSP

MIDDLEWARE.append("django.middleware.csp.ContentSecurityPolicyMiddleware")

# To enforce a CSP policy in report-only mode:
SECURE_CSP_REPORT_ONLY = {
    "default-src": [CSP.SELF],
    # Add more directives as needed.
}

If you are already familiar with the external django-csp package, you may have noticed some slight differences in syntax.

As shown in the comment of the snippet, you can add more CSP directives as you please. This is where the previously mentioned flexibility comes in. You can either write the CSP directives directly in the settings file, or have some logic still in the settings to read from an env.

At the project settings level, you can ensure that certain directives cannot be removed or added without changing the state of the codebase, but that can prove rigid if changes are often required. At the environment level (.env), you can frequently change things, but risk breaking things if the patterns or string literals do not match what is expected. And a combination of both environment and project levels can give you the best of both worlds, only if you make sure that you don't unintentionally make overrides to some directives you otherwise would have liked to leave.

I tested the Wagtail dot org and Bakery Demo sites, and all the cases work as expected, with no visible difference in performance.

Thoughts

I think this is a huge step for Django for a lot of reasons.

Django aims to follow Python's "batteries included" philosophy, and already includes a lot of security features. I think CSP would make a great addition to that list.
A lot of users may not have already been aware of the concept of CSP, but even the idea of them seeing it in a changelog or "What's new?" section would easily bring this to their notice.
The external Django-csp tool is a powerful tool, but I imagine the community feedback on an equivalent Django internal would lead to better iterations.
I also like the idea of CSP decorators that will let you fine-tune the CSP configurations for each view!

Conclusions

I'm looking forward to seeing this feature in Django 6.0, and I'll definitely be on the train of people updating functionality on Django sites that I contribute to. I feel adding this to the already-included "Django batteries" is the right direction.

Special credits to Rob Hudson for taking charge of this feature.

Thanks for reading!

Persisting Config Files Across Computers

Chiemezuo — Fri, 21 Feb 2025 23:07:46 +0000

Introduction

Isaac Newton's famous third law of motion says: "For every action, there's an equal (in size) and opposite (in direction) reaction." A classic case of this is how the thrill of getting a new machine is often matched by the dread of setting up the said machine. With developers, for instance, the list of things to migrate can go on endlessly. From SSH keys to tools (or their equivalents in a different operating system), account details, program files, environment setups, and configurations. These can take a chunk of someone's time. Even worse, some of them (e.g. configurations) are only possible to the extent of the previous machine still being available. I imagine configurations being a nightmare to remember if something crashes unless there is a previous backup available on demand. I'll talk about a nifty way of keeping configurations.

Backstory

I recently switched devices and found myself using the zsh terminal. It seemed very compatible with the bash commands that I was more familiar with, but I had a big gripe with it right away: "tab completions were not case-sensitive". This was a big deal because I like the idea of my directory names being capitalized, and having to account for this caused a lot of friction. I decided to switch to bash in the hopes of that being resolved, but I had no such luck. I figured I would have to play around with my terminal configurations and found some commands that did this. I created the required .zshrc file, copied the commands, saved them, and tested them. It worked, but I encountered another problem shortly after: My active GitHub branches weren't showing in the terminal.

I use branches a lot, and having the one I'm in show on my terminal is a big relief, and saves me the stress of manually checking every time. This is something I cannot live without, and I got some code from the internet to add to my .zshrc. Things worked fine, but three questions came to my mind:

Would I always have to do this while setting up a new machine?
What if I (or someone else) accidentally deleted the .zshrc file?
What if I made a change and wanted to undo it later on?

The third question had the easiest solution: write comments for every new addition. And while having a trash folder felt like an answer to the second question, it wasn't guaranteed that it would always be retrievable.

As for the answer to all the questions? Well, that's what I'm here to talk about.

The Approach

I shared some of my annoyances with the new setup process with a friend of mine and we talked about possible ways of solving these problems. He mentioned a solution he developed for himself after several years of switching machines because he had very precise settings he liked to keep. Hint: it involved Version Control.

Version Control allows you to track and store different states of a file, with an option to store these versions in a remote repository. This answers the 3 questions from earlier, but brings with it, its own question: "How?"

There are two ways of doing this with git:

Make the location of the .zshrc a git repo.
Have the content of the .zshrc file in a different location (which will be a git repo), and then point to that location.

The first approach seems good at first glance. However, the usual location for the .zshrc file is in the home directory, which also has lots of files. To achieve the desired result, you would need a .gitignore file in place to ignore everything else except the pertinent config file. The drawback with this is that you could somehow end up committing something new (and sensitive) or even damage something in your home directory while setting up. It's a high-risk low-reward process.

The second approach, on the other hand, might seem a bit confusing to do at first, but is safer. The trick to achieving this is knowing how to point files to other files, similar to how variables work in programming languages. This is where Symbolic links (symlinks) come in. A symlink is a file that points to another file. Beneath the hood, it's simply a file that contains a text string file path, in a format that the operating system understands to follow up with. Essentially, we could write the configs in a safe (or even public) location, and have their counterparts in the home directory point to them instead. This way, you could make a change in the new location, and everything would reflect as expected. Best of all, you could commit changes without fear of damaging anything, and replicate the process for as many different machines as you want.

The Process

The first step would be knowing how to create a symlink. For POSIX, the shell command to do this is:

ln -s <target-path> <link-path>

Where the <target-path> is what you want to point to, and the <link-path> is the copy that points to it. Let's say you have a file a in the documents directory and you want to make it read-only and accessible from the desktop directory, the command would look like this:

ln -s path/to/documents/a path/to/desktop/a

The path/to/desktop/a will be created if no such file exists, but the path/to/documents/a should ideally exist, else there would be nothing to be linked to.

For my symlink, I created my new .zshrc file in the following path:

Documents/Code/Scripts/dotfiles/.zshrc

Afterward, I initialized the Scripts folder into a git repo and pushed it to my GitHub remote. Having done this, I edited the .zshrc and filled it with the copied-over commands from my findings.

By default, shell terminals look for configuration files in the home directory (~/). My next step was to link one to the target I created in the git repo. To do this, I ran:

ln -s Documents/Code/Scripts/dotfiles/.zshrc ~/.zshrc

I reloaded my terminal afterward, and all my new terminal configurations worked. To be sure changes would reflect, I appended some random characters to my target file and ran cat ~/.zshrc to see if the characters would reflect, and that worked. Essentially, problem solved.

Takeaways

With this technique, I can persist not only shell configs, but also other text file settings I would like to carry along to other machines, and it would take me only one terminal command to get everything working as intended.

Going even further, I could have this for multiple types of files, and then have a script.sh that I could run to set up everything automatically. For example, the following:

ln -s path/to/target/.zshrc ~./zshrc
ln -s path/to/target/.zshrc_profile ~./zshrc_profile
ln -s path/to/target/.zshrc_completion ~./zshrc_completion

would make ./script.sh a convenient script to run, especially on a new machine.

A Few Things to Note

The target file and link file do not need to have the same name. It just helps for recognition.
The .zshrc file would work similarly to .bashrc, depending on the shell terminal you're using. The principles still hold.
These methods are not limited to just configurations and will work in pretty much any situation where you need to have something in a location you would rather not turn into a repo, but would like to keep for future usage.
There are different types of config files. I used the one I was most familiar with.

Credit

Special thanks to my friend Tom for pointers on how to solve the problem.

Finally, thank you for reading.

Cheers. 🥂

How a Lottery Quest Led Me to The Powers of PyTorch

Chiemezuo — Sat, 28 Dec 2024 22:15:56 +0000

Introduction

At some point in time, you have probably heard that your chances of winning a lottery are very slim. As with all things related to probability, multiple trials might tilt an outcome in your favor. Now, if you were to participate in many lotteries, your chances of winning one would be a bit better, depending on how many more lotteries you participated in. This is still by no means a guarantee that you will eventually win, but with uniform distribution, and going by the law of large numbers (in this case meaning a large number of lotteries), we can arrive at relatively more likely possibilities.

It's important to understand that each new lottery is independent of any other, and the same lottery "ticket number" could win many different lotteries (following the law of large numbers). You could also be unlucky and pick the wrong number in every lottery, regardless of how many times you tried. You have two options now:

You can try a random number every time.
You can try the same number every time.

Theoretically (and mathematically), both scenarios have an equal likelihood of occurring. However, scenario 2 will give you a slight edge. As the number of times approaches infinity, every number will eventually be selected. The problem is that with scenario 1, you need to try more times with the hope that the number you've picked at the time matches the number that wins. With scenario 2, you're sure that as the trials tend to infinity, your number will at some point "win". For this blog post, we will use scenario 2.

So, do you think you can answer this question before I tell you the answer?

"If all lotteries around you had slots for exactly 1 million people and you picked the same ticket [x] for everyone you played, how many lotteries would you have to play to finally be a winner?" (Feel free to comment on what your initial answer was)

The answer is...

About 14.4 million times.

The rest of this blog post will be about how I arrived at that value, how the simulations were done, and some caveats. Things will get more technical from here.

The Logic

The ticket numbers of a lottery of 1 million people would range from 1 - 1,000,000 (or 0 - 999,999). Players can only pick a number within that range for each lottery, and the winning ticket can only be from that range. Essentially, we can say we will have a set of 1 million numbers.

Accounting for the fact that a user can pick any number within that range, we need to satisfy the condition of every item in the set being hit at least once. This is because if every number has been called at least once, it would cover any possible ticket number a player could have picked. This also means we do not care about how many times each number runs, making a "set" the ideal Python data structure to use for our simulation. We will start with an empty set, and populate it with a randomly generated number at each iteration until the set contains every number within the specified range. Since Python sets do not repeat numbers, we do not have to worry about ensuring uniqueness.

def calculate_lottery_chances(lottery_players_count):
  number_set = set()
  count = 0

  while len(number_set) < lottery_players_count:
    gen_number = random.randint(1, lottery_players_count)
    number_set.add(gen_number)
    count += 1

  return count

For a lottery of 1,000,000 people, the function call would look like: calculate_lottery_chances(1000000), and it would return the number of lottery attempts before winning. Arranging the code in this manner makes it very extendable.

The Problem

In a nutshell, the root cause of the problem is "variation". The first time I ran the function, I got "13.1 million" times as my value. I reran it, and got something along the lines of 13.9 million. I did this even more times and got widely varying answers -at some point, I got 15 million. It was clear that I would need to do this and find an average. Following the existing pattern so far, I figured that as the number of iterations to average it by tended towards infinity, I would be closer to having one reliable answer. There was a need for something that could do this, and do it fast, and that led me to write this function:

def average_over_n_times(function, function_arg, n):
  """
  This returns the average of the returned value of a function
  when it is called n times, with its (one) arg
  """
  total = 0
  for x in range(0, n):
    total += function(function_arg)

  return round(total/n)

Subsequently, everything would then be patched up as:


num_of_trials = average_over_n_times(calculate_lottery_chances, lottery_players_count, n)

Where "n" would represent the number of times to average results by. This, however, brings up another problem that will be discussed in the next section.

What should "n" be?

The larger the value of n, the closer to an "average-case" result. However, considering that there are still no absolutes or certainties, performing this series of tasks too many times stops being productive. I say this for the following reasons:

Time is not infinite, and we cannot perform these calculations indefinitely, meaning that there will always be a variation (no matter how little) each time it is run, defeating the idea of an "absolute".
Computational resources are finite.
One of the assumptions of this experiment is that "randomness" as generated by computers can accurately mimic reality.
Just as with algorithm runtimes, smaller magnitudes stop being as important as the greater ones. A variation of about 100,000 wouldn't be as significant when dealing with values greater than 13,000,000.

Keeping these in mind, I tested "n" with the values: 10, 20, 30, 50, 100, 1000, and 5000 times.

Where does PyTorch come in?

At this point, you're probably wondering why the word "PyTorch" in the title of the blog post hasn't even been mentioned. Well, although I mentioned testing n with different values, it wasn't the same code I used for all the tests.

These were computationally heavy experiments, and my CPU had a word with me. The code snippets I shared earlier were written in one file that had zero external package dependencies, and the file was run in the bash shell with the time command prepended to track execution times. Here's what the execution times looked like when using just the CPU:

n	Time (min and sec)
10	1m34.494s
20	3m2.591s
30	5m19.903s
50	10m58.844s
100	14m56.157s

At 1000, I couldn't get the program to work anymore. I wasn't sure if it broke halfway and failed to stop the execution, but I canceled it after 4 hours and 57 minutes. There are a few factors I feel influenced this, which I will discuss in the "caveats" section. Anyway, my fan noise was blaring, and I knew I may have pushed my laptop's modestly powered CPU a bit too much. I refused to accept defeat, and while thinking of what I could do to at least run 4-digit iterations, I remembered something a friend of mine who worked with PyTorch told me:

"GPUs are generally more efficient at computationally intensive tasks than CPUs"

PyTorch uses the GPU, making it the perfect tool for the job.

Refactoring

PyTorch would be used for calculations for our purposes, so refactoring the existing calculate_lottery_chances() code would mean changing CPU-reliant numerical operations and switching to suitable PyTorch data structures. In a nutshell:

The Python set() data type would no longer suffice.
The Python randint() function would be swapped for its PyTorch equivalent.
Seeing as the set() data type would be insufficient, there would be a switch to generating a tensor of zeros that matches the size of the lottery_players_count, with a boolean to indicate whether or not a number had previously won.

The refactor of calculate_lottery_chances would look like:

import torch

def calculate_lottery_chances(lottery_players_count):

  seen_numbers = torch.zeros(lottery_players_count, dtype=torch.bool, device='xpu')

  batch_size = 10000
  count = 0

  while not torch.all(seen_numbers):
    # Generate a batch of random numbers
    random_numbers = torch.randint(
      0, lottery_players_count,
      (batch_size,),
      device='xpu'
    )

    seen_numbers[random_numbers] = True
    count += batch_size   

  return count

I set my device as "xpu" because my computer uses an Intel Graphics GPU, which PyTorch supports.

Output

To ensure my GPU was used during execution, I opened my Windows task manager and navigated to the "performance" section before running. On running, I saw a noticeable spike in GPU resource usage.
For context, here is a before vs after:

Before:

Notice the GPU usage is at 1%

After:

Notice the GPU usage is at 49%

For the runtimes for varying values of n, the GPU was several times faster. It ran values of n below 100 consistently at less than a minute, and was able to calculate for a value of n at 5000 (five thousand!)

Here's a table of runtimes using the GPU:

n	Time (min and sec)
10	0m13.920s
20	0m18.797s
30	0m24.749s
50	0m34.076s
100	1m12.726s
1000	16m9.831s

To have a visual sense of how large the performance gap between the GPU and CPU operations was for this experiment, here's a data visualization to think about:

The x-axis was capped at 100 because I could no longer get realistically "timely" output from the CPU, thus leaving no room for comparison with the GPU. Performing the experiments with numbers within the range of 1000 - 5000 gave me about "14.4 million times" as a result, more often than not. That's how I got the answer from earlier.

Caveats

This experiment made assumptions and relied on certain ways of doing things. Additionally, my inexperience with PyTorch potentially means there may have been a more efficient approach. Here are some factors to consider that may have influenced either the accuracy of my findings or the execution times:

I made a subtle assumption that computer-generated randomness mimics randomness in real life (the physical world).
While I switched a bit of the logic to use PyTorch, the rest of the code still relied on the CPU. For instance, in the average_over_n_times() function, it's possible that both the addition in the loop and the averaging may have benefitted from PyTorch equivalents. I suspect there would have been a performance boost.
I'm unsure of the impact of the batch_size I used on accuracy and performance.
All CPU and GPU tests were done with my PC plugged in, to allow the machine to work at its best. Running them with a device on battery power may see longer runtimes.
PyTorch's CUDA might have the edge over "XPU", but my PC doesn't have support for the former.
I avoided letting my PC "sleep" during the tests. Tests may potentially take longer to run if your computer sleeps.

Finally, I'd like to point out that this was my first time using PyTorch for anything, and I was quite impressed with the performance.

Conclusion

When I went down the rabbit hole with this, I didn't expect to see such gains in performance. I learned the idea behind tensors and a few things about the supporting mechanisms behind even more computationally complex tasks. You have the freedom to use, replicate, or modify the code snippets as you please.

Thank you for indulging me, and I hope you had a fun read.

Till next time,

Cheers. 🥂

Google Summer of Code '24 Final Submission

Chiemezuo — Thu, 22 Aug 2024 15:30:56 +0000

I'm so excited to be writing this. Some months ago, I indicated my interest in contributing to the Wagtail CMS project for the 2024 Google Summer of Code program, and my proposal to "improve alt text capabilities" was accepted.
Story time!!

Background

In the Wagtail CMS, "blocks" are the simplest units for storing content. They work similarly to Django's model fields and forms. For every type of data you would want to store in Wagtail, there is a variety of blocks. CharBlock for characters, DateBlock for dates, IntegerBlock for integers, and so much more for types that their prefixed names represent.

Apart from these primary blocks, Wagtail has some more advanced blocks such as PageChooserBlock for "choosing" page objects, and ImageChooserBlock for choosing images from the gallery of already-uploaded ones or for uploading and then selecting. Here's a full list of blocks in Wagtail.

My project involved working with the ImageChooserBlock that looked like the following in an empty state:

The Problem

When an image gets chosen, the ImageChooserBlock looks like:

Wagtail leaves the implementation of alt text mechanisms in the hands of the developers that build with it, and the only fallback for missing alt texts is the image's title. The title field gets auto-populated with the image's filename on the computer. This field is editable but is often ignored by editors. Here's a survey carried out on Wagtail sites where alt texts were graded on a scale of 0-5. About 54% of images on the web pages examined had poor alt texts, and 22% had completely meaningless alt text. Among the 22% were mostly alt texts that looked like computer defaults.

Project Goals

To provide a new and improved ImageBlock with support for handling contextual image alt texts.
To add a new description field to the image model.

What I did

I created an RFC to communicate my proposed changes in technical detail with the Wagtail core team.
I created a new ImageBlock with full backward compatibility with the ImageChooserBlock, hence removing the need for data migration.
I created a new description property for the AbstractImage class.
I made documentation efforts on both.
I wrote tests for all of the new features I introduced (included in their PRs).
I updated the official demo site's repository to replace the ImageChooserBlock with the newer and more recommended ImageBlock.
I collaborated with my mentors to develop a proposed image alt text flowchart for Wagtail.

The Current State

At the point of my writing this, the RFC has been merged, while the ImageBlock and description field PRs are still being reviewed. Feedback on those two PRs looks good but needs more reviews before a merge to the codebase. The expectation is that these changes will feature in Wagtail's 6.3 release, which should be on the 1st of November, 2024.

Challenges

Among some of the challenges I faced with the project were:

Scope change: Certain unexpected things came up, and adjustments were made. I was consequently also unable to work on the project's stretch goals.
Community requirements: My mentors and I always carried the community along in all the decisions we were to make. It came at a bit of a cost because feedback wasn't as rapid, and in some cases, the community opted for a different approach from what we had in mind. Regardless, the synergy was worth it.
Codebase internals: Some of the fixes involved deeper parts of Wagtail's internal code, and I found myself frequently reaching out to maintainers for more clarity and advice.

Lessons

I learned a lot about collaboration, time management, working as a community, and reaching out for help.
I also significantly strengthened my understanding of git, after frequently damaging my commit histories.

Overall, I learned much more about Wagtail and the magic behind what it does.

Potential Future Modifications

As is, the ImageBlock can be modified to have a suggestions UI. This suggestion UI can prompt the editor to re-use the image's description and then populate the alt text field with it.
A possibility of using AI models to help generate alt text for the images, and then prompting with the suggestion UI. AI models perform quite well with image alt texts in general, and suggestions from them would be of great help in nudging editors to be more thorough (and creative) with alt texts. For a proof of concept, I built a loosely coupled Chromium-based browser extension to show how AI models excel with alt text.

Credits

It took other people's additional efforts to achieve this project's objectives. I was privileged to work with the following people/groups:

My mentors Storm Heg and Saptak Sengupta.
Wagtail's GSoC coordinator Thibaud Colas.
Wagtail's lead developer Matthew Westcott.
LB, Tomasz, and Vince Salvino for their reviews of my RFC.
Wagtail's Accessibility team.
Wagtail's Core team.

GSoC Week 12

Chiemezuo — Mon, 19 Aug 2024 22:28:00 +0000

This was my penultimate week (going by the timeline for the final submission), so there was less new code being added, and more thorough testing of the code I'd already written.

Weekly Check-in

We had no meeting because Storm was on holiday and Saptak had a clashing meeting. There wasn't much to discuss, so we opted to catch up on Slack. The Slack discussions circled around making decisions on some of the questions that Thibaud raised when reviewing my pull requests.

Challenges

I probably unlocked superpowers because I didn't quite hit many stumbling blocks. I suppose that's one of the perks of working on a codebase for several weeks.
What I did find a bit challenging, however, was fixing up the bulk_to_python method in my ImageBlock. The implementation I'd had up to that point defeated the purpose of the bulk method because in the case where the received data previously belonged to an ImageChooserBlock, it ran a database query for each individual ID contained in the list elements. Fixing this required my going through the methods in the parent classes to get a sense of how things ran so that I could take advantage of the parent class' method. Afterwards, I would have to convert the format to something the ImageBlock could work with. It was simple, but it sure wasn't easy.

What I learned

I kept hitting some errors that made progress more difficult for me. I ended up running to Chat-GPT for some answers, and I made a nice finding. The following two code blocks might look the same but are very different.

for value in values:
            if isinstance(value, int):

if all(isinstance(value, int) for value in values):

I was stuck trying to get the latter to work because it looked "fancier" and more concise than the former, and this was because it was inherently wrong, although seemingly correct.

The first block of code goes through a list and checks each item in the list for a condition. The second block might look like it does the same thing, but I realized that the part after the if was a "generator expression" (as explained by ChatGPT). This meant that it would always evaluate to True because it was interpreted as "if there's a generator expression" rather than "if the output of this generator expression is true". Switching to the former solved the problems I had, however, it took a lot of debugging for me to find out that the error was actually from the if statement. I spent so much time logging every layer of the ImageBlock, the values for the methods, and the values in the parent class methods before making my findings.

After fixing the error though, I tested as thoroughly as I could and pushed my changes. All that was left were a few more comments that I thought I would resolve in my weekly meetings with Thibaud. However, he was unable to attend the meetings, so I pushed the final touches for the following week. I also asked my mentor to look into a CI error I was getting all of a sudden. We weren't able to get to the bottom of it and decided we'd face it squarely in the last week. This week, more than ever, I was so confident about finishing my Summer of Code program on a high note.

Thank you for reading this far, and kudos to you if you actually somehow followed up on this series.

Till next time.
Cheers. 🥂

GSoC Week 11

Chiemezuo — Mon, 19 Aug 2024 00:22:45 +0000

I apologize once again from releasing this quite late, but in preps for concluding my Summer of Code program, I've been working for longer hours trying to patch certain things up, and the toll of the program has been somewhat heavy. The good news is that things are looking quite good from my perspective, and I'm sure I'll be on track for the final submission period. This summary of the week will be brief because I spent most of the time reading reviews of my PRs and making fixes to things as requested by the reviewers.

Weekly Check-in

My mentors and I touched on a few topics, one of which was about the fact that this project's work would likely feature in Wagtail's version 6.3 release. This would mean a lot more time to absolutely fire-proof the code, while still giving us a good timeline for the GSoC final submission.

We talked about the overall progress report of the project and the fact that my RFC had finally been merged!

I discussed my Internet Connectivity issues which I'll explain later, and Storm hinted at me updating the fixtures file for the demo project repo to reflect the changes I had made in the admin interface.

It was more or less a very straightforward meeting, and there was a mutual understanding of the week's tasks.

Challenges

I couldn't do as much as I would have normally done for the week because I had a big setback: internet connectivity. There was a nationwide protest in my country (Nigeria), and in a reactionary measure (possibly as instructed by government agencies), major Internet Service Providers shut down internet services. I couldn't even load simple web pages anymore. All my meetings lagged, my GitHub refused to connect, and I couldn't even install packages for a proof of concept I was trying to do for the next major iteration of this project (outside the scope of GSoC). This internet outage happened in the middle of the week, so things got unproductive quickly. To try to catch up, I moved my working hours to nighttime because the Internet was a little bit better at night, long after the protest hours. I had to do this for about 3 days, although it was quite tough getting my body to adapt to the sudden change in timing.

The next challenge I'd say I had was with some reviews that had open-ended questions. This was not a bad thing in itself, but it left me in a position where I wasn't entirely sure which of the options would be best for any given process. I did push for some more experienced Wagtail contributors to weigh in on the questions and comments.

Again, because I had bad internet problems, I wasn't able to do as much, and therefore didn't have too many challenges.

What I learned

Most of all, I'd say that for the week, I learned about the inevitability of unforeseen circumstances. I felt deeply helpless and embarrassed when my Internet went off. I also found myself wondering about just how much of my life revolved around computers and the internet. It felt like a sign to go and touch a bit of grass.

I also saw the importance of having multiple backups for essentials like the Internet (although the backups I had also failed). Overall, sometimes things really are beyond our absolute control, but that's okay. It's life, and life has a way of humbling us all.

Thank you for reading this far.

Till next time.
Cheers. 🥂

GSoC Week 10

Chiemezuo — Wed, 07 Aug 2024 09:11:33 +0000

In any project, it's expected that a couple of things will change a little bit, often because there is more information now at one's disposal. Some other times, it's because of an extra creativity that comes when a person is moving at a good enough pace. Regardless of the situation, a mental compass of the initial direction is still needed not to derail too far. We, once again, made some design alterations.

Weekly Check-in

My mentors and I walked through the previous week's challenges and successes and reviewed the progress so far. I also mentioned reaching out to people higher up in Wagtail for help with another issue I'd encountered with the Suggestion UI in the previous week.

Storm talked about his holidays and discussed his availability during that period. Saptak didn't plan on going on any holidays right away so he would still be available till the end of my GSoC program for the most part. I mentioned how Thibaud offered to take some time from his own holidays to help me round up my GSoC project.

Finally, my mentors told me to get started with preps for the blog post I would have to make. I would first have to start with an overall idea of what I would like it to look like, and then build upon it.

Here's some extra good news: My RFC has been approved and is currently awaiting a merge upon completion of the "waiting time".

Challenges

The problem with the Suggestion UI is that there was no "readily" supported way of retrieving Python database values from the Javascript side of the logic, and those values couldn't be sent from Python to the form because the expected initial data would always be None or "empty". I discussed with Matt (Wagtail's lead dev) and he mentioned that there were some things in the Telepath.js library that could potentially be changed, but that it would involve some level of complexity. Nearing the completion of my GSoC program, additional levels of complexity, especially on internal tooling that I had never worked with before felt like a lot of effort in the wrong direction. I discussed it with Thibaud, and he mentioned that he would look at it, but that if it felt like a lot of extra unplanned work, then it could be worked upon iteratively after my GSoC program by either any Wagtail dev or me. I was largely in support of moving it aside because it was a blocker for the rest of the projects.

However, the biggest challenge I faced in the previous week was the "undocumented" series of problems that happened as a result of the nationwide protest in my country. The government shut down some parts of our Internet access and electricity system. This made it particularly difficult for me to do any work, and at some point in time it was impossible to even access Git and GitHub. For two working days in the previous week, I couldn't do a single thing except clean up code offline (I couldn't even push). This meant I had to work during the weekend to account for time wasted beyond my control. I also noticed that Internet access was more bearable at night time, so I had to tweak my working schedule. It did take a physical toll on me, but it's the only way I was able to get work done.

What I learned

I realized that the more I had to explain the code I had (and why it did what it did), the more my fundamental understanding of Wagtail blocks got better. I have become much better at spotting properties and attributes of models in Wagtail. I also now know how to confidently access the docstrings at will. In one of the reviews, Thibaud pointed out how I could check code test coverage, and Storm mentioned modifying fixtures for the bakerydemo setup project. I hadn't previously known about them in Django, but I got to do some reading about them in this article about fixtures.

Once again, I fried my commit history when I was trying to revert some changes I did somewhere else. It took me on another rollercoaster where certain commits were doubled, but this time, it was on one of the primary branches I was working on. I panicked at first, but after some time (and lots of effort), I decided that I would be able to start over if it got damaged beyond repair. In my adventure battling this problem, I learned the powerful "drop" keyword when rebasing, and thoroughly vetted what I was dropping with help from GitHub's interface to verify the hashes. Much to my happiness, it did work out just fine. It's safe to say I'm developing superpowers with Git.

The week had its ups and downs, but few things move linearly, and I'll take the wins and lessons from the losses.

Thanks again for reading this far.

Till next time.
Cheers. 🥂

GSoC Week 9

Chiemezuo — Thu, 01 Aug 2024 23:41:14 +0000

Compared to the previous weeks, this week had little "excitement", but I was particularly grateful for that. Sometimes, stability beats excitement, because one can only keep on for so long. Let's dive right in.

Weekly Check-in

My mentors and I went through the previous week's work. My tasks from the last week were mostly successful, so there was positive news on my end. I also had to open up to my mentors that given the situation of things, the stretch goal of using AI to generate alt text was looking less feasible. They understood, but we agreed to discuss more about it in the coming week.

We particularly talked about pending tasks that were stalling the completion of the PRs. I drafted a work outline of how I planned to approach completing the changes provided I did not encounter any esoteric Wagtail internals that would require special assistance. Storm mentioned his holiday starting in the coming week, so I mentioned that I'd work a bit faster so I could make the most out of his current availability before the holiday time comes.

Thibaud and I agreed to bi-weekly (twice a week) sessions where we could address bottlenecks and blockers. His own holiday would be starting on the 1st of August, and he promised to dedicate some of his time to helping me out, especially in the would-be absence of my primary mentor Storm.

Finally, the weekly check-in ended with my mentors notifying me about an internship post I would have to make towards the end of GSoC. Storm told me I would probably receive the official email soon, but he wanted to give me a heads-up so I could brace myself for it.

Challenges

I faced some really tough challenges trying to render a custom form template for my new block. Of course, I eventually had to reach out to Wagtail's lead dev for help towards the end of the week because I was hitting a brick wall. He was kind enough to give me some history about Wagtail, and why a certain development choice they made interfered with the default process I was trying to account for. He also gave me something to look at, and some helpful snippets of patch code I could write for this. This did work, but led me to another challenge which I would move to the following week, as it was already the weekend, and I had spent so much time trying to fix things.

That was the most challenging problem I faced, as everything else I was to do felt very familiar.

What I Learned

Among my technical tasks for the week, I had to update the bakeryDemo examples to use the new Block as the Wagtail standard. This then prompted me to read the contributing docs for the bakerydemo project, and consequently, it prompted me to look deeper into Django fixtures. It's on my list of things to read, and I just might write about what I've learned from it.

Exploring the form template for the ImageBlock also exposed me to the crafty way Wagtail mixes a bit of server-side rendering with client-side rendering, and by extension, the Telepath.js library. That was/is a part of Wagtail I had barely ever touched, so my curiosity got the better of me.

Finally, I had to move the release notes because these new features would no longer be candidates for version 6.2. I tweaked them and temporarily moved them to a Google Doc, to be shared when it's time to make the changes.

As a side fun fact, I think I'm gradually getting the hang of the versioning systems.

Thank you once again for reading this far.

Till next time.
Cheers 🥂

GSoC Week 8

Chiemezuo — Fri, 26 Jul 2024 18:04:30 +0000

I initially lacked the zeal to write about this week, but decided I had to, because I promised myself I'd write about my GSoC on a weekly experience. Also, I'd be annoyed with myself if I chickened out. My lack of zeal was reflected in the fact that this blog post was overdue for several days. The week didn't quite go as I had planned, but it was good, and afterward, I spent the weekend away from my computer. This was the week my mentors and I finally decided to change some parts of the new functionality we'd spent weeks working on.

Weekly Check-in

This wasn't like our regular weekly check-in meetings. It started about an hour later than usual because we had to accommodate Thibaud's schedule so he could walk Storm through the changes and they could deliberate on them. It was a somewhat lengthy session because we all had valid concerns. On the one hand, Thibaud wanted upgrades with the least friction for users, even if it meant compromising the initial goal. On the other hand, Storm and I wanted to do things the "right" way: making sure that the usability of alt text was not left to the chance that editors would modify their image title fields.

At the same time, it would be fair to say that we all had our biases. Thibaud was speaking as a developer and editor who already had accessibility in mind in his daily work, while also working in a company where other people followed best practices. Storm was speaking as a developer who frequently worked with editors and had seen lots of people not bother to follow best practices. On my end, I was speaking as a developer from the perspective of a newcomer, who could easily see all the ways to do things "faster" without any extra overhead (even if the overhead would be a better way to do things).

After going through the flowchart together and looking for what was best for our existing users, we decided to leave the defaults as they initially were. This would mean I would spend the week undoing changes I made in a previous week. It didn't sound exciting, but the work had to be done, nonetheless.

This reminds me of Matthew Wescott's (Lead Wagtail Dev) video on the impossible art of pleasing everyone. The compromise wasn't exactly something I was absolutely sold on, but sometimes these things are out of our control, and the consequences of our actions would mean a good or bad experience for editors who use Wagtail.

Challenges

I could write an entire book about all the challenges I faced, but for now I'll write a couple of paragraphs instead. I had an absolute nightmare with git. I also learned about a misconception I'd had about git reverts.

Before I started the GSoC project, Wagtail's default to fallback to the title field in the absence of any alt text mechanism. There were also a series of tests to ensure this behaviour. However, because my mentors agreed earlier on that this would change, I edited all the pertinent tests to remove this behaviour. Several weeks later, I would have to bring them back. There were two ways I could do this:

I could look at the git diff from the current state of things and manually edit things.
I could just "go back in time" and "stop myself" from making those changes (but to appear as an activity done in the future)

Believe it or not, the first process was easier, but I felt there would be a lot to learn from step 2 so I opted for that instead. This is where the chaos started. All along, I'd always thought that git revert would alter things in the commit history so I deliberately avoided doing that. I had the very bright idea(you probably understand the sarcasm) of checking out to the older commit hash and manipulating things from there. This was uncharted territory for me so I decided to do all of this in a copy branch of the branch I was working on. That sole activity saved me.

I checked out to the branch and then to the particular commit hash. I tried to undo a few changes and commit, but then I somehow messed with the history. I'm not even sure I can entirely explain what went wrong, but I kept getting a series of merge conflicts. At some point I made a mistake in one of the merges and had to undo that. Then I tried rebasing to fix that issue. At this point, I went from trying to get a small change done, to tirelessly bombarding ChatGPT with prompts, because I could no longer understand what I was doing. I ended up with about 13 commits for one simple task, and several merge conflicts that would always pop up any time I did a git pull. After hours on that hamster wheel, I decided to start afresh because I had made such an inexplicable mess of things.

This time around, I started by outrightly asking ChatGPT what to do. It mentioned "reverting". This put me on high alert, but I decided to do some extra study and read more about git reverts. After reading a bunch of articles, it looked very okay (much to my surprise), and I decided to try it in a different branch. I deleted the one I had messed up and started again. I can tell you for a fact that I was surprised at how smooth everything went. It worked well, and I had zero issues. This, however, was only one part of the equation. The other part was to merge it to the actual branch I needed it to be on. I said a quiet prayer with the hopes that nothing would go wrong (because that was essentially several weeks of progress). Again, things worked, and I finally pushed.

What I Learned

In a nutshell, I learned a lot about how reverts, soft resets, and hard resets work. Let's just say I won't forget when to use them in a hurry. Experience really is the best teacher.

I also learned the importance of always opening different branches to try out new things. There's a good chance I could have damaged my commit history if I didn't create that sandbox-like environment for myself. In a sense, that's the whole point of git: the power to break things to your heart's content without actually damaging anything.

Finally, I'd say I learned to question my preconceived notions more often. Why did I feel so strongly about reverts when my knowledge was wrong? I can't quite say, but going forward, I'll be more open-minded about things.

Conclusion

It was a chaotic week, but some level of chaos is required for some level of growth. Apologies if you religiously follow-up with this series and expected this to drop sooner. I'll do a much better job next time.

Thank you for reading it this far.

Till next time.
Cheers. 🥂

GSoC Midterm Evaluation

Chiemezuo — Mon, 15 Jul 2024 00:00:21 +0000

This week was the week for both mentors and contributors to turn in their evaluations. Mentors would give feedback on the experience with mentees, and mentees would do the same for mentors. Spoiler alert: I passed mine at the end of the week. 🎉
Let's get right to my summary of the week.

Weekly Check-in

My lead mentor (Storm) was on holiday, so Saptak led the session. We started with a rundown of the state of the project so far. I mentioned that the PR for the new ImageBlock was in good shape, I was making some good findings on the AI stretch goal, the image_description still needed extra feedback, and my documentation (as well as the release notes) were also coming up nicely.

Saptak mentioned wanting to get the RFC moving faster so that we could get it approved/accepted by the core team, to meet the GSoC timeline. He mentioned he'd try to push it across to some other people to get more comments on it.

We agreed that for the rest of the sprint, I would ideally try to get the PR ready for review again, and I would also get a proof of concept ready for the AI stretch. One of the most exciting parts of my Summer of Code was about to commence. The agreed progression was to start the AI project as a regular Django project, and then modify it to suit Wagtail's needs iteratively. I was asked not to worry too much about the UI, but to get the basics up and running.

Accessibility Team Meeting

A few minutes before the Accessibility team meeting, I got a message from Thibaud. He had some concerns with the RFC and mentioned that he felt it required a bit more work. He wanted the RFC to be more detailed in covering the behavior for various use cases of the block, as well as how the changes would affect existing usage even when the block wasn't used. He mentioned the idea of developing a flowchart, which he eventually did with me after the Accessibility meeting, over a call. It was quite a long call, but I appreciated the time he put in, and we had a good discussion on what I could do to communicate this flowchart better in the RFC itself. It did mean I would have to go back to the drawing board, though.

What was particularly a debating point (which still hasn't been resolved) was whether Wagtail should keep the existing behavior (of defaulting to image titles) in the absence of any form of alt text. Image titles are meant to be brief, and are usually whatever the image was saved as in the computer (unless the user changes them). In lots of cases, though, the titles make very bad alt text. With no alt text, Wagtail's Accessibility Checker would easily flag a problem. With bad alt text, the Accessibility Checker wouldn't find it. At the point of my writing this, there are modifications in the works to improve the Accessibility Checker's ability to spot bad alt text patterns, but I'm working in parallel because I'm not sure how soon it will be ready.

Thibaud is of the opinion of falling back to titles, but my mentors and I are not. We will take it up with the accessibility team again, as well as the core team to gather overall thoughts. We will conclude in the coming weeks, though.

The meeting ended with some potential UI features we could integrate if the GSoC timeline permits. It also meant that I wouldn't be able to mark the PR as finally ready for a review till the pain points were settled.

Challenges

My biggest challenge came from trying to get the AI project prototype to work. This was largely because I didn't have any OpenAI access keys. I couldn't seem to get one from Thibaud earlier in the week so it halted my progress greatly. I set up the project template from the OpenAI docs I had read and tried to make sure that the only delays were from access keys.

I was able to get access keys from a friend of mine, but it had to be during his office break hours before invalidation. It was better than nothing, and I used this up until I got the keys from Thibaud during the Accessibility meeting. That was my major challenge of the week. The next challenge was (and still is) trying to account for the discussions in the Accessibility team meeting.

What I learned

I learned how to use OpenAI's API to take advantage of the multimodal features, I learned about some more use cases of images in models, and I learned how OpenAI works with images.

I'd say my best learning moment came from drafting the Flowchart with Thibaud. It showed me my lapses in knowledge of Wagtail's image management, and it also tested how confident I was in the work I had done so far. These things make all the meaning to me, and I'm glad to be able to learn more (even if it means constantly going back to the drawing board).

Evaluation

It was another great GSoC week, and I passed my midterm evaluations. I got great feedback, and I am excited about the remaining stretch of the program.

Here's my feedback:

Thank you for reading.

Cheers. 🥂

GSoC Week 6

Chiemezuo — Mon, 08 Jul 2024 17:34:36 +0000

Documentation is one of the pillars of good software. We often forget to do it because it comes in as a 'secondary' consideration. My theme for week 6 was 'documenting my features properly', and it was what I did.

Weekly Check-in

We had a lengthy check-in session, especially because my lead mentor Storm was starting a small holiday this week. The topics, however, revolved around putting the finishing touches on pending tasks so that we could progress to the stretch goal (AI). We agreed on a follow-up meeting to discuss the AI requirements on another day.

Among some of the finishing touches discussed were:

Drafting the upgrade considerations that would added to the release notes for whichever new version of Wagtail the feature would fall under.
Updating Wagtail's documentation. In the examples, I would have to replace instances of ImageChooserBlock with ImageBlock, and I would also have to update the StreamField reference guide to show the new block.
Following up with my feedback request on the image description field warning labels.
Making the social media RFC post.
Iterating to make ImageBlock perfectly swappable where ImageChooserBlock has already been used, without any data migrations.
Going through fresh comments on the RFC.

We structured the next sprint from the outcomes of our meeting discussions.

AI Follow-up Meeting

On Wednesday, we discussed the rough (proof of concept) implementation and how to get started. We agreed that our first AI model would be the same as what we used for our research on alt text: OpenAI. We discussed what the contract should look like between our service and the APIs we would use.

My mentors were of the idea that I would start the implementation as a simple Python project, and after getting things to work, we would progress to modifying it to be an extension of Wagtail. The primary focus, however, was on getting the feature set to work. They both gave me some pointers on things to look out for and things to try. We also realized some more questions that would pop up much later in the Wagtail implementation, such as whether to generate many different results with the same prompts at once vs just one result (with the option to trigger for more). There was also the question of whether we would make a UI option to allow editors to modify the existing prompts, or whether to let it be site-wide.

There was also the question of an RFC for the new feature, but we agreed that since we weren't sure of the direction or the complete implementation, we would build iteratively until we had enough knowledge of what to include/exclude from the RFC, as well as questions that may come up later on.

Challenges

I had a couple of challenges, but I scaled through them like a superhero. The first challenge was that I wanted ImageBlock to be a perfect replacement for ImageChooserBlock. In Wagtail, when you want to change the block used, you will very often have to do a data migration. It can be an annoying step, and in some cases might prevent people from upgrading right away, or from changing to the new way of doing things (especially since ImageChooserBlock wouldn't be deprecated). The all-encompassing goal of my GSoC project is to get Wagtail editors to follow best image accessibility practices, and the easier I can make it, the better the chances. I had the ambitious goal of erasing the data migration step.

To do this, I had to modify the new ImageBlock's to_python and bulk_to_python to be able to receive data in the same format that ImageChooserBlock would have received it. The solution involved me adding some conditionals to the methods, and they would check if the received value was an instance of int (image_id). If it were, I would retrieve the image object, and then I would create a dict with the image property, and two other fields for decorative and alt_text and default them to False and an empty string respectively, before calling the next method. Writing the tests for this was another big of warfare, but I got things working.

My last notable challenge was trying to draft upgrade considerations and update the documentation. I had never written upgrade considerations and therefore had to go through some from previous release notes. I did this as a Google Doc draft and got Storm to review it. Afterward, I reached out to Wagtail's lead dev (I'll get permission to post his name here soon) for guidance on what part of the Pull Request to introduce it into, and he gave me feedback. I also asked him if it was okay for me to replace ImageChooserBlock with ImageBlock in the documentation examples it appeared in, as well as any extra pointers to look for. He was perfectly fine with it, and I spent the rest of my week working on docs.

What I learned

I once again found myself in a situation where I wasn't entirely sure of the expected data to be received from a block, but I used the SQLite Browser to inspect what it would look like. Another block was added to my list of competencies. 😅

I learned the process of prepping documentation for features, as well as some little bits of the sphinx tool for documentation in Python projects. I'll also add that modifying the to_python and bulk_to_python methods was a huge learning experience for me, especially concerning how it handled expected data.

I'm getting to the point where I have an idea of where anything I'm looking for in the codebase would probably be found.

This was another great week, and a big thanks to you for reading thus far.

Cheers. 🥂