ontowhee

psycopg2.errors.InFailedSqlTransaction

2026-01-28T00:00:00-08:00

Today my co-worker asked me to help troubleshoot an error they were encountering in one of the existing tests:

psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block

My first thought went to @transaction.atomic. Which blocks of code were wrapped in this decorator, and which were not? The one that wasn’t wrapped in a transaction is likely failing.

I ran the test on my local machine and inspected the traceback.

======================================================================
ERROR: test_order_template (order.tests.test_views.OrderTestCase.test_order_template)
----------------------------------------------------------------------
Traceback (most recent call last):
    File "/myapp/venv/lib/python3.12/site-packages/django/db/backends/utils.py", line 108, in _execute
    return self.cursor.execute(sql, params)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block

...

    File "/myapp/context_processors.py", line 61, in locations_processor
    model = MyModel.objects.select_related('related_field').first()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...

    File "/myapp/order/views.py", line 552, in get_order
    return render(request, 'order/order_template.html',
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...

django.db.utils.InternalError: current transaction is aborted, commands ignored until end of transaction block

Full traceback

Year 2025 (Abridged)

2026-01-18T00:00:00-08:00

“It was the best of times, it was the worst of times…”

– A Tale Of Two Cities, Charles Dickens

4 Books
3 Conferences
2 PRs
A Shifting Mindset
Djangonaut Space
Arts & Wine Festival
Radio Station
Newsletter
Reflecting On Writing A “Year In Review”

4 Books

These books stood out for the voices, experiences, and resilience they portrayed:

Crying In H-Mart - Michelle Zautner, Alfred A. Knopf, 2021
The World Of Nancy Kwan - Nancy Kwan, Legacy Lit, 2025
Where Rivers Part: A Story Of My Mother’s Life - Kao Kalia Yang, Atria Books, 2024
Melt Down: The Making And Breaking Of A Field Scientist - Sarah Boon, University Of Alberta Press, 2025

3 Conferences

North Bay Python

This two-day, one-track conference is oriented around community. I presented a talk on Djangonaut Space, met several people in-person whom I had only known from online, reconnected with people I met last year, and enjoyed the rainy albeit cold weather along with the views (and smells) from the barn.

DjangoCon US

This was pivotal for me. I felt more like myself than I had in the past two decades. I volunteered to stuff swag bags, helped out at the registration desk, said yes to delivering a morning announcement as well as the Sprint kickoff, reconnected with people from the previous year’s conference, presented a talk about Djangonaut Space, met new people and had many discussions. Seeing my mentors in person was a huge highlight. Helping out at the conference made me feel I was more part of the community.

I also had the chance to roam Chicago, enjoy the River Walk (and the river waft ;P), take in the morning sun at the lake, and experience the transportation system, which I think is superior to the system where I live in terms of the frequency of trains and affordability.

It’s crazy to think that I was having second thoughts about attending the conference just a month before. I’m glad I booked my flight and room and took on challenges that came my way. There were still moments of deep insecurity, but sharing my insights and experiences shaped my sense of place and purpose. There were lots of different aspects about participating in the conference and exploring a new city that allowed me to grow.

PyBay

I volunteered at the registration desk, met new people and also reconnected with people from previous conferences. The talk I found most interesting that day was Mason Egger’s Events are the Wrong Abstraction. It reminds me of the argument for monoliths and against microservices.

It was a long and fun day, starting with an early morning drive in the dark into the city for volunteer duty, good conversations during lunch and break times, followed by dinner in the evening with the volunteer team and speakers.

2 PRs

Most proud code contributions to Django so far:

It’s always a joy to bring clarity to something that can feel nebulous at times. While the code changes are small, the bulk of the work was in scouring the forum, repository issues, looking into existing examples in other communities, scraping data instead of relying on a data dump, taking on different aspects of the contribution process first hand (triaging, bug fixing, reviewing, etc.) and learning the nuances of the existing tools and workflows. Even then, I was just exposed to a small sliver of all the work that goes into maintaining the web framework. I did have fun (as well as frustrations) exploring Trac, and its configurable design is quite fascinating, despite not having data integrity. It relies a lot on string search.

The hardest part for me was presenting a logical argument for the importance of these initial changes and bigger changes down the line, especially to those who have this information so ingrained in them that they don’t see the need for the changes. Many people guided me along the way, from opening an issue to starting a forum discussion. I was able to demonstrate the value for these changes. The Django Fellows reviewed the PRs and helped get the changes merged in.

The change to the contribution workflow diagram broke the PDF docs builds in the 6.0 release. A community member filed the report, and another quickly submitted a PR fix for it.

I’m proud of these changes because I know there is at least one person who uses them very often: me. I reference the diagram whenever I talk to new contributors. I use the queue links to navigate to the tickets all the time. I’m also proud of these changes, because establishing a clear mental model of a “queue” versus a “triage stage” paves the way for more improvements. This is the tip of the iceberg.

A Shifting Mindset

Software engineering interview funnel:

9 invitations
6 screening rounds
3 final rounds
2 offers
1 accepted (1 rescinded)
3 invitations turned down after accepting an offer

Of the 9 invitations, 7 were through recruiters or referrals, 2 were cold applications. I lost track of the total applications.

Time spans for the two offers:

Longest: 6 weeks
Shortest: 11 business days

Non-software engineering role:

1 Sales Associate role

When things didn’t seem to materialize, I explored non-software engineering roles that would allow me to acquire customer-facing skills. I applied and was accepted for a Sales Associate role. I took the job… and walked out after 5 hours. Funny story, it was Louis Rossman’s video from a decade ago that inspired me to apply and take the job. It was also another one of Rossmann’s videos that helped me “flip the switch”.

Mail-in applications:

Yes, I sent my resume via snail mail for a software engineering role at a big food delivery company. Initially, I questioned it’s legitimacy, did a quick search on the mailing address, and then took a chance. Several months later their recruiter emailed with an invitation to schedule the screening interview. At first, I was very confused, because I didn’t remember applying to this company, and I couldn’t find any references to it in my computer files. Eventually, I did find a screenshot of the job post. I turned down the invitation as I had already accepted an offer.

–

It was a rocky journey, and I was hesitant to share this. However, my experience here is not unique, and it dominated the year. Besides, what’s the point of pretending the track record is pristine? The bumps and how they were handled are more interesting.

I have many people to thank for helping me along the way. Everything from encouraging me to create an online profile, to reviewing my resume, to tips on having social media activity (social proof), to encouraging me to negotiate (because negotiation IS part of the process and part of everyday life), to the many referrals. The most important part was having people believe in me when I didn’t believe in myself.

At the beginning of the process, I was afraid of letting people know that I was looking for opportunities, and I was afraid to ask for help. By the end, I was scheduling the earliest available interview slot for every invitation. I was excited to meet new people, learn about their busienss needs, share my experiences, and be myself. If I’m perceived as a Type-A personality by one of the interviewers, I know it’s temporary. Interviews can be awkward and exaggerations of reality.

The search process made me understand that there’s nothing to be ashamed of. A layoff, multiple rejections, and even a rescinded offer are nothing in the grand scheme of things. The fact that I hadn’t had more rejections shows that I hadn’t been reaching for more opportunities and aiming higher.

A few years ago during Salesforce Dreamforce, I met a high performing salesperson from Marketo. We were discussing the mentality of salespeople and what drives them to hit their goals in the context of gamification. This person told me, “Salespeople get a thrill when they see their numbers go up. They don’t care how many deals they lose. They care about how many deals they win.”

Djangonaut Space

I was a Navigator for Session 5. In my role as a mentor, I curated a list of tickets to help the Djangonauts get started. I exposed them to other ways of contributing, by showing them examples of triage work and PR reviews. When I was a Djangonaut, my Navigator had shared his own experiences of a ticket that he was working on at the time. I did similarly by sharing my work and experiences.

The Djangonauts not only got their PRs merged, but they also contributed by writing for Django News Updates, writing for the Django web blog, writing their own personal blogs, and posting on the forum. I introduced them to Space Reviewers, and the team participated in a live episode to review a PR. It was amazing to see how much the Djangonauts accomplished in the 8-week time frame.

The best part of any good mentorship is that we are all mentors to one another. I learned a lot from the Djangonauts and the Captain. It wasn’t always smooth sailing. There were moments where I wondered if I was being effective as a mentor. In the end, it was very satisfying to see that the Djangonauts have developed confidence as well as a growing appetite for making contributions. I look forward to seeing more of their work and hearing more about their stories.

Arts & Wine Festival

At an Arts & Wine Festival one summer weekend, I worked the ticket booth on Saturday and the beer booth on Sunday. For the ticket booth, it was challenging trying to keep the line moving while also trying to improve the setup. This reminds me of finding the balance between building new features and addressing technical debt on software projects.

My co-volunteer was very smart about handling the new ticket packaging system that was introduced this year. The festival attendees were very confused by it, but my co-volunteer would start by asking them how many drinks they expected to have, then worked backwards to show them the package that would get the best deal.

My co-volunteer and I also coordinated such that one person handled the payments and the other person handled the tickets, wrist bands, and beer/wine glasses. We still needed the festival organizer to observe from a distance to see the bigger picture of the bottleneck though.

The beer booth on Sunday was less hectic. I learned to pour beer (with the glass at an angle to reduce foam) and greeted the festival attendees who were excited to get their drinks. I also got to know my co-volunteers, a mother-daughter duo who live in my neighborhood.

Radio Station

I took a radio station training course, passed the exams, and completed my studio training sessions. I also volunteered at a few station-hosted events, including a live mic and a film festival.

For the live mic, I showed up unannounced. I had no idea what to expect. I bet I confused people when I showed up, too. I was just curious and wanted to help out at the studio before taking the exams or starting the training. The staff members were very welcoming. One of them patiently showed me how to operate the controls for the 4 video cameras. I ended up operating the controls that evening, trying to decide what shots looked interesting, when to apply the panning and zooming effects, and how to pace the transitions between the cameras. I also had the chance to meet the surf bands. They were very friendly. One was The Frigidaires, hailing from Atlanta. The other was LHD, traveling all the way from Croatia.

For the film festival, I helped put up vintage film posters to decorate the auditorium and set up the merch table. I managed the ticket admissions at the opening of the event. I applied a similar setup that I learned from volunteering at the ticket booth at the Arts & Wine Festival: one staff member handles the payments, while the other handles the tickets. During intermission, I helped people find their t-shirt sizes at the merch table.

It’s always fun looking for ways to improve the process ever so slightly, so attendees don’t have to wait too long in line in the freezing night. It was fun greeting the attendees and helping them buy t-shirts. I met more staff members, many who shared stories of their connections to the station pre-dating my existence. They, too, were excited to meet me and welcome new members to the station.

I attempted to write a weekly newsletter. I haven’t quite figured out the format and type of content. Do I share about my projects or dive into details of topics? Do I share more news-y content about other people’s works and events? At what frequency? Is a newsletter the right format for my interests? I’ll see…

Reflecting On Writing A “Year In Review”

I was on the fence between writing lists and having deeper analyses. Trey Hunner’s “My Favorite Reads Of 2025” inspired me to get going with a books section. For certain topics I found myself diving deep. Paolo Melchiorre took the approach of giving each topic its own dedicated blog entry, but my problem was less about writing, and more about sharing. I mulled over 5 different drafts across 5 days, and delayed publication several times over the period of a month. After working through those thoughts, I realized I don’t have to share them if I don’t want to. And yet, I want to!

Reflecting On Speaking

2025-10-24T00:00:00-07:00

DjangoCon US 2025 was in Chicago from September 7th-11th. Four months earlier, I had delivered a talk at North Bay Python (NBPython) titled, “Djangonaut Space: A Mentorship Program For Open Source”. The proposal I submitted for DjangoCon US was the same as for NBPython, but I was very dissatisfied. I didn’t want to give the same talk. I didn’t like the content, and I didn’t like my delivery.

In preparing for DjangoCon US, I reflected on my contributions and experiences in the time since NBPython, and I was able to include new material. However, as I was practicing my speech, I would clock in at 35 or 40 or 45 minutes, instead of the allotted 25 minutes. I didn’t want to cut out the new material and water it down to the original talk. I tend to speak slowly and softly. It’s a reflection of my uneasiness. I realized if I could speed up my speech, perhaps I can get all the content in, and I can also appear more lively. So, instead of cutting out the material, I challenged myself to speak faster and more energetically. As I was practicing, I was able to clock in closer to 25 minutes.

In the actual talk, I spent the first 3 minutes of the time slot trying to update my computer settings to show my notes. I couldn’t deliver without my notes, because I was reading it verbatim, so I knew I really had to speed up my speech. There was no time to slack. I remember feeling very out of breath around the 9 minute mark, but I kept going. My speaking time clocked in at about 20 minutes! I even had remaining time for one question in the end.

Being able to share my experiences from the Djangonaut Space program to a room filled with my mentors, as well as strangers turned acquaintances, was amazing. I’m glad it worked out. I’m glad I was able to portray how much the program means to me. I liked how the slides turned out, especially the chart on slide 15. The original slide was just bullet points of text. I’m glad I was able to challenge myself and grow even more.

It was wonderful afterwards when people came up and told me they enjoyed my talk. Some asked how they can apply to be a mentor. It is amazing to see that several of those people are now participating in the program. I don’t think my talk alone was the major reason for people getting involved, but I imagine it played a role in bringing awareness to the program and revealing perspectives and raw emotions.

After challenging myself to speak physically differently than I normally do, I feel I have opened myself up to the world. I’ve shown myself that I can take up space. I can project my voice. I don’t have to feel apologetic for any of it. I don’t have to default to thinking I am inferior to anybody else. Quite the opposite. I think people have wanted me to take up space and speak up for a long time. Someone with a big name in the community who I admire told me they noticed a huge difference in me, and they are very happy to see it.

Tutorials, Testathons, Sprints, Space Reviewers

2025-07-29T00:00:00-07:00

Two weeks ago, I joined Raffaella and Sage for Space Reviewers Episode 6, where we reviewed a Django PR during a live stream. This was a fun event. I won’t get into the technical aspects of the review, and I won’t point out the many mistakes I made. Instead, I want to revisit several “getting started with open source” community events and reflect on my personal growth since I first got involved with open source.

My first open source contribution happened accidentally during DjangoCon US 2023. I volunteered to host office hours to help tutorial attendees set up their development environments. I went through the tutorial projects, found a missing dependency in one of them, and reported it on the Slack channel. The conference organizer, Tim Schilling, responded and suggested that I open a PR to the project. I remember thinking to myself, “Really? I can do that?”

During the Sprint Days of the conference, I participated and opened two PRs to address accessibility issues. I didn’t know much about accessibility at that point, and I would not have known how to navigate the contribution process and pick out issues on my own. Thankfully, the project leaders were there to guide new contributors, and I was able to gain hands-on experience with these first few PRs.

There was another event that took place during the Sprint Days called Testathon. I had heard of hackathons before, but I had not heard of testathons. I attended and found out they were like live stream coding or group pair programming. One person shared their screen and the group chimed in on strategies. The purpose of the testathon was to show people how to test open source projects against Django’s beta release. The code driver (or anyone else in the group) would point out what files to look for, how to run tests, and how to open PRs. Every project is slightly different, from project setup to contributing etiquette, and I learned several different things from attending 2 testathons. I loved the interactive and intimate nature of the event. It exposed me to another aspect of open source projects and contributions. I also thought it was very brave of people to share their screens and work through code together in a group. My brain would have short circuited if I were put on the spot like that!

From DjangoCon US 2023, I participated in 3 different types of events where I got hands-on experience with open source contributions, and I wanted more! I was curious about the live stream coding and group pair programming opportunities, too. This was definitely outside of my comfort zone, and I wanted to know how I could overcome my own inhibitions and participate more actively. I wanted to be able to jump into events so nonchalantly as everyone else seemed to do. (Of course, that’s the perception. Now, I know that most people feel some level of nervousness or anxiety when they are hosting or attending such events, and that’s absolutely normal.)

In March 2024, when the first Djangonaut Space session came to a close, Tim, a program organizer, asked if anyone was interested in hosting a “Getting Started With Contributing” event. I expressed my interest, and Tim suggested a ticket to work on. Unfortunately, I didn’t follow through. How could I host a “Getting Started With Contributing” event? First, I wasn’t sure if I even knew how to get started. Second, I wasn’t ready to lead an event and the discussions while simultaneously sharing my screen and thinking out loud. Finally, I wasn’t ready to be on camera in the public eye. Even though I had just finished the Djangonaut Space program, I hadn’t overcome my own inhibitions. I didn’t ask for guidance, and the event never materialized.

About 8 months later in November 2024, Space Reviewers launches its very first episode. I thought it was such a creative format. I wanted to be a part of it. By this time, I was getting a lot of training with event organizing through my role as the Session Organizer for Djangonaut Space, but I wasn’t sure how to ask about joining the Space Reviewers crew, and maybe it was too early in the formation of the group to bring on another member.

It wasn’t until June 2025 that I finally asked if I could help out with Space Reviewers. The crew welcomed me as a new member. I started out by making a pre-recorded video, a PR Review Deep Dive, that was uploaded to the Djangonaut Space YouTube channel. I had a lot of fun recording and editing the video.

A month later in July 2025 (that is, two weeks ago), the crew members planned for the next episode. Raffaella scheduled time for the event and created the show notes, and I was taking on Tim’s role as a co-organizer. Because I would be managing the video stream and sharing my screen, I realized that I could be the single point of failure during the event. There was no safety element that a pre-recorded video offers. If my internet went down, or if my computer crashed, or if I stupidly clicked the wrong button, the live stream could come to a halt. It was a terrifying thought, but I took on the risks and pushed forward.

On the day of the event, there was a delay to the start time and some fumbles on my end, but overall, it was very fun and productive. People joined and shared their tips and tricks in the live chat. By the end, we were able to walk through the review process and post our comments on the PR. Looking back, I think making the pre-recorded video was a great stepping stone towards hosting the live stream.

I’m so glad I had the opportunity to work with Raffaella and Sage as part of Space Reviewers. They have a lot of insights and perspectives that I didn’t have. I had a lot of fun taking on the new challenges that came with organizing this event. Initially, I struggled internally as I tried to face some of my fears. There were moments leading up to the event where I thought to myself, “Why did I volunteer to do this???” In the end, I’m glad I did.

Some of the challenges I overcame might not seem like a big deal, but when I compare myself to where I was at the beginning of DjangoCon US 2023, I can see my personal growth quite prominently. Now, I know how to get started with contributing, and I am able to walk people through the process. I am also a lot more comfortable taking ownership of organizing and leading events. (I remember a time when I constantly needed to ask for permission or confirmation before executing an action.) I can brush off the fumbles I make as the camera is rolling, and I can continue on with the discussion.

When I revisit the community events that I have participated in over the past 2 years, from Space Reviewers, to Sprints, to Testathons, to Tutorial office hours, I realize how far I have come. I am also reminded of what it was like to be absolutely new to open source and to the community. Although I still feel somewhat new, I’m not a deer in headlights anymore. I’m still trying to find my place in open source, and the best way to do that is to continue showing up and continue helping out. One small PR at a time, one small review at a time. One little blog, one little video…

Consensus… Or Collections?

2025-06-13T00:00:00-07:00

In the Django process for making changes, one is encouraged to post on the forum and start a discussion with the goal of gaining consensus.

I drafted a proposal for a change to the Triage Workflow, but I don’t think I will post it. The proposal is flawed in its one-size-fits-all approach to the solution. Attempts to “gain consensus” can drive us into this trap, this belief that a solution should reach agreement from every participant in the discussion.

What if gaining consensus is the wrong goal? What if the real goal is to create a collection of solutions?

What if the proposal is not actually about changing the Triage Workflow, but rather about suggesting different layouts of the Trac web interface, where each layout is tailored towards a contributor role? For example, in some applications such as Salesforce, there is a dropdown menu that allows you to “switch roles” and see different widgets on the dashboards based on your role as an Account Executive, or a Sales Development Representative, or any other role that you would like to create and customize.

The Reports Tab achieves this collection-of-solutions approach already. It provides a rich list of preset filters. But, how easy is it to use? How many people know about it? I’m talking specifically about people who are non-super contributors. This could include new contributors, as well as experts who do not contribute on a high frequency basis, as well as community organizers who use the ticket management system for reasons other than development work.

Is there value in a multi-layout solution? Is there a way to display the information from Reports Tab differently, so it is more easily accessible? For example, display a tab for each section of the reports tab, and labeling the current “View Tickets” tab as “Custom Query”.

To be continued…

Creating A Temporal Table To Track Django Development Process

2025-05-26T00:00:00-07:00

Temporal Table

Temporal data refers to data that is associated with time periods. A time period consists of a start time and an end time.

A temporal table is a database table that stores time periods. There are two types of temporal tables. One is application-time versioned table, the other is system-time versioned table. The difference is the meaning behind the stored time value.

In application-time, the stored time value reflects the application state. For example, it can be the activation and deactivation dates of a membership to an organization. Application-time is useful for tracking the history of the application state.

In system-time, the time values reflect the moment the data is modified. System-time is useful for auditing purposes.

SQL:2011 Temporal Features

SQL:2011 introduced the standards for temporal features. These standards include defining a time period using the PERIOD declaration, DML for UPDATE and DELETE, period predicates such as OVERLAPS, CONTAINS, and EQUALS to compare time periods and use them in conditional expressions for filtering and ordering.

It also includes table constraints to ensure the time period columns are an ordered pair of datetime/date fields that satisfy the bounds of the time interval when a PERIOD is declared. It also describes primary key and foreign key constraints applied to the time periods.

PostgreSQL does not yet implement temporal tables. There is ongoing work in Patch #5660 to add support for application-time.

We won’t be using built-in database temporal features. Instead, we will be creating a temporal table by adding the ordered pair of time columns. We will manage the data in the application layer.

Trac

Django uses Trac for ticket management. When we visit a ticket page, we see two main sections: a ticket details section, and a change history section.

Figure 1 is a screenshot of ticket #12090. It shows the current state of the ticket, including the fields Reported By, Owned By, Cc, Triage Stage, Has Patch, etc.

The “Change History” section shows how the ticket has been modified over time. In Figure 2, we can see the values of ticket fields such as Status, Triage Stage, and Cc transition from their old value to new value. This section also includes comments and attachments that were uploaded to the ticket.

A look into the Trac schema shows two tables, ticket and ticket_changes. These tables correspond to the ticket details and change history sections. Here are their schemas:

...

Table('ticket', key='id')[
	Column('id', auto_increment=True),
	Column('type'),
	Column('time', type='int64'),
	Column('changetime', type='int64'),
	Column('component'),
	Column('severity'),
	Column('priority'),
	Column('owner'),
	Column('reporter'),
	Column('cc'),
	Column('version'),
	Column('milestone'),
	Column('status'),
	Column('resolution'),
	Column('summary'),
	Column('description'),
	Column('keywords'),
	Index(['time']),
	Index(['status'])],
Table('ticket_change', key=('ticket', 'time', 'field'))[
	Column('ticket', type='int'),
	Column('time', type='int64'),
	Column('author'),
	Column('field'),
	Column('oldvalue'),
	Column('newvalue'),
	Index(['ticket']),
	Index(['time'])],

...

Notice that the ticket_changes table is not a temporal table. It only contains one time field. That is, it captures a point in time, rather than an interval of time. This makes it difficult to query for information such as the duration of something, or to know if something was valid at a given time. However, it is a log of data changes, and we can use it to reconstruct the temporal data.

Creating Temporal Table For Triage Stages

Trac data is acquired by downloading the html pages for a ticket. Data for the ticket details section is extracted using BeautifulSoup. Data for the “Change History” section is extracted from a javascript variable called changes.

We are building a Django app. We create a Ticket model to store the ticket details. Additionally, we add a JSONField called changes to store the data as-is from the javascript changes variable .

from django.db import models


class Ticket(models.Model):
    cc = models.TextField()
    changetime = models.DateTimeField(null=True, default=None)
    changes = models.JSONField(null=True, default=None)
    component = models.CharField(max_length=128)
    description = models.TextField()
    easy = models.BooleanField(default=False)
    has_patch = models.BooleanField(default=False)
    keywords = models.TextField()
    needs_better_patch = models.BooleanField(default=False)
    needs_docs = models.BooleanField(default=False)
    needs_tests = models.BooleanField(default=False)
    owner = models.CharField(max_length=256)
    reporter = models.CharField(max_length=256)
    resolution = models.CharField(max_length=128)
    severity = models.CharField(max_length=64)
    stage = models.CharField(max_length=64)
    status = models.CharField(max_length=64)
    summary = models.CharField(max_length=256)
    time = models.DateTimeField(null=True, default=None)
    type = models.CharField(max_length=64)
    ui_ux = models.BooleanField(default=False)
    version = models.CharField(max_length=10)

Next, we create a QueueHistory model, and the underlying table for this model is our application-time versioned table. We add two datetime fields, valid_from and valid_to, and together they create the time period. The other fields in the QueueHistory model hold the information about the state of the development process during this application-time period.

class QueueHistory(models.Model):
    ticket = models.ForeignKey(Ticket, on_delete=models.CASCADE)
    queue = models.CharField(max_length=30)
    author = models.CharField(max_length=128)
    has_patch = models.BooleanField(default=False)
    needs_better_patch = models.BooleanField(default=False)
    needs_docs = models.BooleanField(default=False)
    needs_tests = models.BooleanField(default=False)
    resolution = models.CharField(max_length=128)
    stage = models.CharField(max_length=64)
    status = models.CharField(max_length=64)
    valid_from = models.DateTimeField()
    valid_to = models.DateTimeField()

PostgreSQL has tstzrange and daterange data types, and Django supports these data types with the fields DateTimeRangeField and DateRangeField. We won’t be using this field type. We’ll be sticking to creating two separate datetime fields. The decision behind this lies in having the flexibility to switch between PostgreSQL and SQLite (which could come in handy if we choose to use Datasette or another tool later).

You may be wondering why this model is called QueueHistory instead of StageHistory. We’ll explain more in the next section, but ideally the queue and stage would be synonymous.

Insights For The “Big Gray Area”

We are building a standalone project, completely independent from Django’s Trac system. This provides flexibility to experiment with new stages.

With the current Django Triage Workflow, there are 3 triage stages:

Unreviewed
Accepted
Ready For Checkin

There are also ticket resolution values to indicate why a ticket is closed: duplicate, wontfix, invalid, worksforme, needsinfo, fixed.

In our experiment, we will refer to stages as queues for two reasons: 1) avoid confusion with the original triage stages, and 2) ultimately we want queues to be a feature in the UI of the ticket management system.

We break the original Accepted stage into 3 new queues. We also separate the Needs Info resolution into its own queue, and we add Someday/Maybe as a queue as well.

Our queues are:

Unreviewed
Needs Info
Someday/Maybe
Needs Patch
Needs Review
Waiting On Author
Ready For Checkin
Closed
Unknown

We define constants for our queue labels.

# constants.py

class QueueLabel:
    UNREVIEWED = "Unreviewed"

    # Waiting On Info
    NEEDS_INFO = "Needs Info"
    SOMEDAY_MAYBE = "Someday/Maybe"

    # Accepted
    NEEDS_PATCH = "Needs Patch"
    NEEDS_REVIEW = "Needs Review"
    WAITING_ON_AUTHOR = "Waiting On Author"
    READY_FOR_CHECKIN = "Ready For Checkin"

    # Closed
    CLOSED = "Closed"

    # When combination of fields do not correspond to any known queue
    UNKNOWN = "Unknown"

We define a function to calculate the queue value given a snapshot of the ticket state as determined by the following fields: stage, status, has_patch, needs_better_patch, needs_docs, and needs_tests.

def calculate_queue_value(snapshot):
    def check_values(snapshot, **kwargs):
        boolean_fields = {"has_patch", "needs_better_patch", "needs_docs", "needs_tests"}
        string_fields = {"stage", "status"}
        return all([
            snapshot[k] is v
            for k, v in kwargs.items()
            if k in boolean_fields
        ]) and all([
            snapshot[k].lower() == v.lower()
            for k, v in kwargs.items()
            if k in string_fields
        ])

    if check_values(snapshot, stage="Unreviewed"):
        return QueueLabel.UNREVIEWED

    if check_values(snapshot, has_patch=False, status="Closed", resolution="needsinfo"):
        return QueueLabel.NEEDS_INFO

    if check_values(snapshot, status="Closed"):
        return QueueLabel.CLOSED_FIXED

    if check_values(snapshot, stage="Someday/Maybe"):
        return QueueLabel.SOMEDAY_MAYBE

    if check_values(snapshot, stage="Ready for checkin"):
        return QueueLabel.READY_FOR_CHECKIN

    if check_values(snapshot, stage="Accepted", has_patch=False):
        return QueueLabel.NEEDS_PATCH

    if check_values(snapshot, stage="Accepted", has_patch=True, needs_doc=False, needs_tests=False, needs_better_patch=False):
        return QueueLabel.NEEDS_REVIEW

    if check_values(snapshot, stage="Accepted", has_patch=True, needs_better_patch=True):
        return QueueLabel.WAITING_ON_AUTHOR

    return QueueLabel.UNKNOWN

Reconstructing Queue History

To reconstruct the queue history, we loop through each change item from the Ticket.changes field to gather the timestamps to fill in the valid_from and valid_to values, and we gather the old and new values of fields to get the ticket state snapshots.

def reconstruct_queue_history(data):
    """
    Creates a list of dicts with the following fields:
        "ticket_id",
        "author",
        "queue",
        "has_patch"
        "needs_better_patch",
        "needs_docs",
        "needs_tests",
        "resolution",
        "stage",
        "status",
        "valid_from",
        "valid_to",
    These dicts are used to create QueueHistory.
    """
    # Fields that impact queue
    fields = [
        "has_patch",
        "needs_better_patch",
        "needs_docs",
        "needs_tests",
        "stage",
        "status",
    ]

    # Only consider the changes that have modified fields.
    # Skip changes where the fields being modified do not impact the ticket's queue.
    changes = []
    for change in data["changes"]:
        modified_queue_fields = set(fields) & set(change["fields"].keys())
        if len(modified_queue_fields):
            changes.append(change)
    changes = sorted(changes, key=lambda elem: elem["date"], reverse=True)
    changes.append({
        "date": data["ticket_details"]["time"],
        "author": data["ticket_details"]["reporter"],
    })

    # Work backwards to reconstruct the history of the field values.
    cur_values = {
        field: data["ticket_details"][field] for field in fields
    }
    cur_values["ticket_id"] = data["ticket_details"]["id"]
    cur_values["valid_from"] = changes[0]["date"]
    cur_values["valid_to"] = datetime.max
    cur_values["author"] = changes[0]["author"]
    queue_history = [{k: v for k, v in cur_values.items()}]

    # Pair the changes to get the date range.
    for change, prev_change in zip(changes, changes[1:]):
        cur_values["author"] = change["author"]
        cur_values["valid_from"] = prev_change["date"]
        cur_values["valid_to"] = change["date"]
        modified_queue_fields = set(fields) & set(change["fields"].keys())
        for field in modified_queue_fields:
            old_value = change["fields"][field]["old"]
            cur_values[field] = old_value

        # Add to history
        queue_history.append({k: v for k, v in cur_values.items()})

    queue_history = sorted(queue_history, key=lambda elem: elem["valid_from"])
    return queue_history

The QueueHistory objects are created for a ticket and saved to the database. We can run a query to retrieve the QueueHistory items, order by valid_from, and render the data in a chart.

# views.py
def ticket_detail(request, pk):
    item = Ticket.objects.filter(pk=pk).first()
    queue_histories = []
    if item is not None:
        queue_histories = QueueHistory.objects.filter(
            ticket=item
        ).annotate(
            valid_to_cleaned=Case(
                When(
                    valid_to__year=9999,
                    then=datetime.now() + timedelta(days=1),
                ),
                default=F("valid_to"),
            ),
        ).order_by("valid_from")

    template = "trac/ticket_detail.html"
    return render(request, template, {"item": item, "queue_histories": queue_histories})

We use ChartJS to create a Gantt chart with time on the x-axis and the queue labels on the y-axis. We no longer have a big gray area. In the example below, we can see how that the ticket transitions between Waiting On Author and Needs Review eight times before it lands on Ready For Checkin. We can also see the how much time the ticket spends in each queue.

This gives us a clearer picture of what goes on during the development process.

Next Steps

We’ll want to aggregate the data into reports on the component level and queue level.

Searching Django Contributor Activities

2025-05-19T00:00:00-07:00

The search tab on Django’s Trac ticket management system is a powerful tool. It can search for git commits that were merged into the main or release branches. It can search for content on the wiki page. It can also search on multiple fields on tickets.

In this video, I walk through the specific use case of looking for activities from a contributor. I also demonstrate a tool that could make it easier to conduct such searches.

Searching On Names

The search can be used by contributors looking for tickets mentioning specific phrases, or it can also be used by working groups who are looking for activities from contributors.

Here’s a screenshot of looking up a contributor by their name.

The search is able to match on search terms across multiple fields including summary, description, reporter, owner, cc, and comment contents.

However, the results of one search may not provide the full picture about a contributor. For example, searching on the user display name returns different results than searching on the username. This means we have to try different search terms before we can start to get a complete story. We have to be aware of the nuances between username and display name in the first place! That is not quite apparent in the web interface.

Also, the presentation of the results are very raw and not easy to digest. A better mechanism will save a lot of time for looking up a contributor.

Looking Up A Django Contributor Profile

I’m working on a tool, and one of the features allows you to search for a “Django Contributor Profile”. Here’s a screenshot of a contributor’s profile.

It provides a summary of the contributor’s activities. The timeline chart gives a sense of how the contributor has been participating on Trac in the recent times. There is also information on which Triage Stage and which component (contrib.admin, Migrations, Testing Framework, etc.) they are most engaged in. This gives an idea of the contributor’s main roles and areas of expertise.

There is a table with a list of tickets. For each ticket, it shows whether the contributor was the reporter, owner, and how many comments they authored on that ticket.

Next Steps

We can get a good sense of a contributor’s involvement with Django. The next step would be to provide access to information on the component and community levels.

Dataclass For Django Custom Command Arguments

2025-05-14T00:00:00-07:00

Dataclasses

I was cleaning up a custom Django command yesterday and ended using a dataclass as a way to keep the code DRY.

If dataclasses are new to you, don’t worry. Dataclasses are similar to classes, but they have boilerplates that handle many common method and attribute definitions for you. For example, instead of you having to explicitly define the constructor and assign attributes such as below,

class MyClass:
    def __init__(self, param1: str, param2: int, ...):
        self.param1 = param1
        self.param2 = param2
        ...

this code is already defined and hidden away. You just need to define the fields.

@dataclass
class MyClass:
    param1: str
    param2: int
    ...

There are many useful features of dataclasses. In my specific use case, I leveraged a dataclass for two purposes:

To group of a set of variables and logic that are commonly used together.
To centralize default value definitions.

The Original Custom Command

My custom command allows me to scrape a website. It takes in arguments from the command line and builds the url query string for the website. I can run a command like this:

python manage.py scrape --start-date=2025-05-01 --end-date=2025-05-14 --max-items-per-page=20

None of the arguments are required, but they have default values whose constants are defined near the top of the file.

from django.core.management.base import BaseCommand


BASE_URL = "https://code.djangoproject.com/query"
DATE_STR = (datetime.now() - timedelta(days=3)).strftime("%Y-%m-%d")
MAX_ITEMS_PER_PAGE = 100
START_PAGE = 1

...

The arguments are registered with their default values by invoking parser.add_argument(..., default=, ...).

...

class Command(BaseCommand):

    def add_arguments(self, parser):
        parser.add_argument("--start-date", default=DATE_STR, help="Start date in format YYYY-mm-dd")
        parser.add_argument("--end-date", default="", help="End date in format YYYY-mm-dd")
        parser.add_argument("--start-page", default=START_PAGE, type=int)
        parser.add_argument("--max-items-per-page", default=MAX_ITEMS_PER_PAGE, type=int)

...

When the command is run, it instantiates an object for the scraper class using the values from the command line arguments.

...

class Command(BaseCommand):
	...

    def handle(self, *args, **options):
        scraper = TracScraper(
            options["start_date"],
            options["end_date"],
            options["start_page"],
            options["max_items_per_page"],
        )
        scraper.scrape()

...

The constructor for the scraper class consists of keyword arguments which are used to initialize the object attributes. The default values for the keyword arguments are coming from the constants defined near the top of the file. The constructor also includes logic to build the url query string from the attributes.

...

class TracScraper:
    def __init__(self, start_date=DATE_STR, end_date=DATE_STR, start_page=START_PAGE, max_items_per_page=MAX_ITEMS_PER_PAGE):
        self.start_date = start_date
        self.end_date = end_date
        self.start_page = start_page
        self.max_items_per_page = max_items_per_page

        query = f"changetime={self.start_date}..{self.end_date}&start_page={self.start_page}&max_items_per_page={self.max_items_per_page}"
        self.url = f"{BASE_URL}?{query}"

    def scrape(self):
        ...

This seems typical for a custom command. However, there are a few places of redundancy.

While global constants are used to define the default values, referencing them in the function signature of TracScraper.__init__() can feel unwieldy and repetitive when there is a much larger number of command line arguments.
When another scraper class is introduced for the same website, not only will it likely have a similar function signature for its constructor class, but it will also need the logic for building the url.

Using Dataclass

I now use a dataclass that includes a field for each command line argument. It also includes the base_url. The global constants near the top of the file have been removed and their values are set directly on the fields.

from dataclasses import dataclass
from django.core.management.base import BaseCommand


@dataclass
class Params:
    start_date: str = (datetime.now() - timedelta(days=3)).strftime("%Y-%m-%d")
    end_date: str = ""
    max_items_per_page: int = 100
    start_page: int = 1

    base_url: str = "https://code.djangoproject.com/query"

    ...

I add a field for start_url that defaults to an empty string. Then in the __post_init__() method, I included the logic that builds and assigns the query string to start_url.

...

@dataclass
class Params:
    ...

    start_url: str = ""

    def __post_init__(self):
        query_params = f"changetime={self.start_date}..{self.end_date}&max={self.max_items_per_page}&page={self.start_page}"
        self.start_url = f"{self.base_url}&{query_params}"

...

When registering the command line arguments, an instance of the Params dataclass is created with all the fields assuming their default values.

class Command(BaseCommand):

    def add_arguments(self, parser):
        # Instantiate a dataclass where all fields assume their default values.
        p = Params()

        parser.add_argument("--start-date", default=p.start_date, help="Start date in format YYYY-mm-dd")
        parser.add_argument("--end-date", default=p.end_date help="End date in format YYYY-mm-dd")
        parser.add_argument("--start-page", default=p.start_page, type=int)
        parser.add_argument("--max-items-per-page", default=p.max_items_per_page, type=int)

When the command is run, it instantiates an object for the dataclass using the values from the command line arguments, then passes this Params object to instantiate the scraper class.

class Command(BaseCommand):
    ...

    def handle(self, *args, **options):
        p = Params(
            options["start_date"],
            options["end_date"],
            options["start_page"],
            options["max_items_per_page"]
        )
        scraper = TracScraper(p)
        scraper.scrape()

The constructor for the scraper class now consists of just the Params dataclass. It no longer needs to be concerned about defining the function signature with keyword arguments and their corresponding default values. It also doesn’t need to be concerned about the logic for building the url query string. All the variables are grouped together, including the start_url variable derived from the command line arguments.

class TracScraper:
    def __init__(self, params: Param):
        self.params = params

    def scrape(self):
        ...

Full Code

Here is the original custom command file:

from django.core.management.base import BaseCommand


BASE_URL = "https://code.djangoproject.com/query"
DATE_STR = (datetime.now() - timedelta(days=3)).strftime("%Y-%m-%d")
MAX_ITEMS_PER_PAGE = 100
START_PAGE = 1


class Command(BaseCommand):

    def add_arguments(self, parser):
        parser.add_argument("--start-date", default=DATE_STR, help="Start date in format YYYY-mm-dd")
        parser.add_argument("--end-date", default="", help="End date in format YYYY-mm-dd")
        parser.add_argument("--start-page", default=START_PAGE, type=int)
        parser.add_argument("--max-items-per-page", default=MAX_ITEMS_PER_PAGE, type=int)

    def handle(self, *args, **options):
        scraper = TracScraper(
            options["start_date"],
            options["end_date"],
            options["start_page"],
            options["max_items_per_page"],
        )
        scraper.scrape()

class TracScraper:
    def __init__(self, start_date=DATE_STR, end_date=DATE_STR, start_page=START_PAGE, max_items_per_page=MAX_ITEMS_PER_PAGE):
        self.start_date = start_date
        self.end_date = end_date
        self.start_page = start_page
        self.max_items_per_page = max_items_per_page

        query = f"changetime={start_date}..{end_date}&start_page={start_page}&max_items_per_page={max_items_per_page}"
        self.url = f"{BASE_URL}?{query}"

    def scrape(self):
        ...

Here is the updated file in one piece after using the dataclass:

from dataclasses import dataclass
from django.core.management.base import BaseCommand


@dataclass
class Params:
    start_date: str = (datetime.now() - timedelta(days=3)).strftime("%Y-%m-%d")
    end_date: str = ""
    start_page: int = 1
    max_items_per_page: int = 1000

    base_url: str = "https://code.djangoproject.com/query"
    start_url: str = ""

    def __post_init__(self):
        query_params = f"changetime={self.start_date}..{self.end_date}&max={self.max_items_per_page}&page={self.start_page}"
        self.start_url = f"{self.base_url}&{query_params}"


class Command(BaseCommand):

    def add_arguments(self, parser):
        p = Params()
        parser.add_argument("--start-date", default=p.start_date, help="Start date in format YYYY-mm-dd")
        parser.add_argument("--end-date", default=p.end_date, help="End date in format YYYY-mm-dd")
        parser.add_argument("--start-page", default=p.start_page, type=int)
        parser.add_argument("--max-items-per-page", default=p.max_items_per_page, type=int)

    def handle(self, *args, **options):
        p = Params(
            options["start_date"],
            options["end_date"],
            options["start_page"],
            options["max_items_per_page"]
        )
        scraper = TracScraper(p)
        scraper.scrape()

class TracScraper:
    def __init__(self, params: Param):
        self.params = params

    def scrape(self):
        ...

Final Thoughts

What are your thoughts on this particular use case for grouping command line arguments into a dataclass?

I think it is interesting and it also seems like a natural use case. I like how much easier it is to create the scraper class without worrying about redefining the default values for the keyword arguments. It makes the function signature much shorter. It also reduces the likelihood of assigning the wrong default values and having them be out of sync between the scraper class and the command line argument registry.

How have you used dataclasses? What do you like about them?

Another Perspective Of The Django Triage Workflow

2025-05-09T00:00:00-07:00

The Cost Of Wrong Triage Stages

Sometimes the Django development process can be confusing because the ticket flags are not appropriately set. Here are a few scenarios that contributors may find themselves in:

A PR author addresses feedback from a review, but does not unset the Patch Needs Improvement, Needs Docs, and Needs Tests flags to get the ticket back into the review queue.
A merger gets a message from a PR author asking why a ticket isn’t being reviewed. The merger replies to explain the development process and remind the PR author to unset the Patch Needs Improvement, Needs Docs, and Needs Tests flags.
A reviewer starts to review a ticket from the review queue, but after poring over Trac and Github, determines that the ticket should be in the Ready For Checkin stage.
A bug reporter gets confused and feels shutdown when a ticket they had just opened is marked as Closed with the resolution set to Needs Info.

In each scenario, the ticket is in the wrong stage, or the contributor’s understanding is not aligned with the intention of the stage. There’s an overhead for all contributors involved.

Without changing any of the underlying mechanisms, where can we start to help contributors better understand the expectations in the development process so they can collaborate more smoothly? Let’s start by understanding the current workflow.

Current Triage Workflow

Below is a diagram taken from the Django contributing documentation depicting the current triage workflow.

In this diagram, there is a lane for “Open tickets” consisting of 3 triage stages: Unreviewed, Accepted, and Ready for Checkin. There is another lane for “Closed tickets” consisting of different states for the resolution property of a ticket (duplicate, wontfix, invalid, needsinfo, worksforme, and fixed).

It is a good starting point. It may seem simple and straightforward at first, until you get into the contribution process and start to experience some miscommunications and uncertainty. The documentation itself acknowledges the big gray area of the “Accepted” stage.

Another Perspective Of The Triage Workflow

Here is a different take on the triage workflow diagram. Note that it doesn’t change the underlying mechanisms of the triage stages.

It introduces two minor conceptual adjustments:

Explicitly name the 3 distinct stages for Accepted stage: “Needs Patch”, “Needs Review”, and “Waiting On Author”.
Organizes the triage stages along a horizontal axis based on the ticket’s progress. That is, how much work remains in order to get the ticket to the finish line.

3 Distinct Stages For Accepted Stage

Despite mentioning the big gray area of the Accepted stage, the contributing documentation already does a great job of outlining 3 distinct stages. All that was missing was having explicit names for them:

“Needs Patch”
“Needs Review”
“Waiting On Author”

These names are chosen because they make it clear what action needs to happen and which contributor role is responsible for taking that action to move the ticket forward. Having distinct stages and explicit names makes it easier to understand where a ticket stands at a glance. It frees the contributor from the cognitive load of computing 4 booleans and makes it easier to move the ticket into the correct queue.

Imagine being a PR author who has just finished addressing feedback from a review. The author can now go to the ticket and adjust the triage stage from “Waiting On Author” to “Needs Review”. The ticket lands in the review queue. Having explicit stages is so much easier compared to the current workflow, where the author needs to remember to unset the flags for Patch Needs Improvement, Needs Docs, and Needs Tests.

Similarly, imagine being a reviewer who has just finished adding feedback to a PR. The reviewer can change the triage stage from “Needs Review” to “Waiting on Author”. They will still need to consider setting the Needs Docs and Needs Tests flags. However, I think having a triage stage name of “Waiting On Author” provides a much better experience. It creates the image of tossing the potato back to the author, which is more intuitive compared to toggling the value of Patch Needs Improvement.

Depicting Progress

Mapping the triage stages along a horizontal axis helps depict how far along the ticket is to the finish line. The Needs Info resolution state is moved out of the “Closed tickets” section. It is considered to have a lower progress status, so it is placed further towards the left on the axis.

With the existing workflow, when a maintainer marks a ticket as Closed and Needs Info, a bug filer might assume that the maintainer is unfairly suggesting that the progress is 100% (“Closed”). However, in this new diagram, the progress for the ticket can now be interpreted as closer to 10%, and the bug filer can feel that this is a more fair assessment and be more cooperative.

Thoughts?

Does the new view of the triage workflow help you better understand what you need to do to move a ticket forward?

This may not be perfect, and it may be an oversimplification of the Django triage workflow, but hopefully it brings some clarity and reduces the confusion and communication overhead.

A few questions to entertain:

Instead of doing mental gymnastics with the flags Has Patch, Patch Needs Improvement, Needs Documentation, and Needs Tests, what if contributors can easily glance at a ticket and know which stage it is in?
What if contributors can easily move a ticket from one stage to another?
What if contributors can easily pull up the list of tickets in each stage on the “View Tickets” tab, instead of having to switch to the “Reports” tab or find in their bookmarks?
What low hanging fruits can be built into the UI that makes navigating the contributor process more intuitive? What would cut down on the overhead for contributors?

[Next post coming soon…]

Event Organizing

2024-12-01T00:00:00-08:00

It is December. Djangonaut Space Session 3 is wrapping up it’s final week. It makes me happy knowing that the program helps transform a lot of potential into real results.

I want to share my most proud accomplishment as a Session Coordinator — putting together the Djangonaut Showcase event! I’ve never organized events before, and this was a great learning experience for me.

Djangonaut Showcase

It started when I added a small agenda item added to our organizer meeting notes that said:

Ideas:

Showcase event

That item got the ball rolling! During the meeting, I briefly explained that the motivation for this event came from my own desire to have a similar event when I was a Djangonaut. I wanted to share what I learned and to connect with my peers. There were also several sources of feedback that we received during the current session where people expressed the same desire! I was excited to know that I wasn’t alone.

Once I explained the idea behind the event, the organizers were onboard! Then, I spent time during a weekend co-writing session to draft up the proposal. I shared the proposal during the next organizer meeting, and we had a very good discussion to refine the logistics and details. After the discussion, I created a list of action items. Then, it was time to execute!

Send out announcement. Get people to sign up. Send out instructions. Schedule time slots. Check-in to make sure everyone was on track. Prepare to host the event. I made sure to stay organized by putting information on a spreadsheet along with due dates. Timeliness was important every step of the way.

We had a dry-run to make sure I knew how to use Zoom as a host. I practiced delivering the introduction. I’m not very good with speaking and having conversations. My co-organizer suggested writing up a script. So after the dry-run, I wrote up a script and practiced. I recorded myself and played it back several times until I felt comfortable with all the things I had to say and the transitions from one topic to another. The evening of the event, I made sure to go to bed early and get a lot of rest.

The event was a huge success! Two successes, actually! We had two events to accommodate timezones and availabilities. Officers, Stars, and Astronomers showed up to support the Djangonaut speakers. Djangonauts were excited to share their learnings and experiences. Everyone got swept away during the Q&A sessions.

I’m so glad to have a lot of help from the organizers to make this event successful. Was it perfect? No, and that’s ok. Is everyone feeling inspired and motivated and more connected? I think so!

I’m looking forward to seeing the community continue to grow. I’m looking forward to seeing more collaboration among Djangonauts, Stars, Astronomers, Organizers, etc., including myself. I’m personally looking forward to making more contributions, both in code and community organization. My favorite part is working with wonderful, smart, kind people!

Organization Process

Here is breakdown of the steps I took to organize this small, yet impactful, event. It’s a process I will adapt and apply to other events and technical projects, too.

Have an idea for an event in your head.
Sit down to some quiet time during a co-writing session and write the proposal for the event. Have details about the logistics and also the goals.
Share your written idea with other organizers to get feedback and refine the details.
Write up action items. Create a list of things that need to be done. Assign deadlines. Note details about things you need, such as permissions to accounts/tools (zoom, email, etc) to send out communications.
Execute. Be mindful of timelines.
Keep an eye on the sign ups and participation level. If not enough interest is being express, take action early and make announcements. Make sure your messaging is explicit about the expectations for the participants during the sign up process and the event itself.
Prepare for hosting the event. Write up an outline of how the event will flow. Write up a script for what you will say. Write up backup questions to ask in case there is a lull in the audience. Practice, record, practice. Have a dry-run with the help of your co-organizers. Lean into them for feedback and support.
Make sure to get a eat well and sleep well before the event.
Host the event!
Celebrate your accomplishments with friends.
Follow up and collect feedback on the event, if possible, so you can learn from the results and improve on the next iteration!

ontowhee

psycopg2.errors.InFailedSqlTransaction

Year 2025 (Abridged)

Contents

4 Books

3 Conferences

North Bay Python

DjangoCon US

PyBay

2 PRs

A Shifting Mindset

Djangonaut Space

Arts & Wine Festival

Radio Station

Newsletter

Reflecting On Writing A “Year In Review”

Reflecting On Speaking

Tutorials, Testathons, Sprints, Space Reviewers

Consensus… Or Collections?

Creating A Temporal Table To Track Django Development Process

Temporal Table

SQL:2011 Temporal Features

Trac

Creating Temporal Table For Triage Stages

Insights For The “Big Gray Area”

Reconstructing Queue History

Next Steps

Searching Django Contributor Activities

Searching On Names

Looking Up A Django Contributor Profile

Next Steps

Dataclass For Django Custom Command Arguments

Dataclasses

The Original Custom Command

Using Dataclass

Full Code

Final Thoughts

Another Perspective Of The Django Triage Workflow

The Cost Of Wrong Triage Stages

Current Triage Workflow

Another Perspective Of The Triage Workflow

3 Distinct Stages For Accepted Stage

Depicting Progress

Thoughts?

Event Organizing

Djangonaut Showcase

Organization Process