fidzu : python

Today I learned Python 3.15 will get a new sentinel built-in.

Sentinel values are unique placeholder values that are commonly used in programming. Python 3.15 ships with a new built-in sentinel that can be used to create new sentinel values:

# Python 3.15+
>>> MISSING = sentinel("MISSING")
>>> MISSING
MISSING

Before this built-in was added, the most common sentinel idiom used the built-in object:

MISSING = object()

def my_function(some_arg=MISSING):
    if some_arg is MISSING:
        ... # Handle the sentinel

In the function above, the sentinel value MISSING is being used to check whether the user passed anything as the parameter some_arg or not. PEP 661, that introduced this built-in, has a great discussion covering the reasons as to why this pattern, and many other sentinel patterns, fall short. In general, each common sentinel idiom suffers from at least one of the following problems:

1. Bad string repr: the string representation is too long and uninformative
2. Type unsafe: the sentinels don't have a distinct type so it becomes hard or impossible to write code that uses the sentinels and is type safe
3. Unexpected copy behaviour: the sentinels can't be copied or pickled without breaking the sentinel behaviour

01 May 2026 5:49pm GMT

News

PyCharm Campaign Now Includes RENEWALS!

Past or current PyCharm Pro users can now take part in the PyCharm campaign! Add 12 months to your current PyCharm Pro subscription. The same deal applies to past, current, or first time users. Get PyCharm Pro 30% off and 100% goes directly to the DSF! Until May 3rd.

Adopt Annual Release Cycle (DEP 20)

A new DEP from Carlton Gibson proposing that Django move to an annual release cycle. There is a lengthy discussion on the GitHub ticket

What's new in pip 26.1 - lockfiles and dependency cooldowns!

A detailed post of new features from Richard Si, the current maintainer, including pylock files, dependency cooldowns, security fixes, and more.

---

Django Software Foundation

It's time to redesign djangoproject.com

A redesign of the djangoproject.com website is in progress. This post from the Django blog is an update on the project's process: the plan, who's doing the work, and how you can help.

---

Updates to Django

Today, "Updates to Django" is presented by Hwayoung from Djangonaut Space! 🚀

Last week we had 14 pull requests merged into Django by 13 different contributors - including a first-time contributor! Congratulations to Dinesh Thumma for having their first commits merged into Django - welcome on board!

All release note-related changes this week came from Djangonaut Space. 🚀

• Added ModelAdmin.delete_confirmation_max_display option to truncate the list of related objects on the delete confirmation page in django/contrib/admin/options.py, added in Django 6.1 (#10109).
• Fixed the inaccessible "---------" blank choice label in form <select> controls by replacing it with "- Select an option -" via a new BLANK_CHOICE_LABEL setting in django/conf/global_settings.py, added in Django 6.1, and deprecated BLANK_CHOICE_DASH (#35879).

---

Sponsored Link

---

Articles

Running from Django's main development branch in production

Carlton Gibson makes the case for running Django off of Django's main development branch rather than waiting for security and feature releases.

Before GitHub

Armin Ronacher, of Flask and other open-source Python fame, looks wistfully at GitHub's decline and points out that Open Source did not always work this way.

Leaving GitHub as a Social Network

David Guillot points out the many red lines that Microsoft has recently crossed and debates other alternatives.

pgBackRest is dead. Now what?

One of several posts on the longtime sole maintainer of pgBackRest stepping away. This is a fundamental tool for PostgreSQL and a general failure in the open source ecosystem. Additional posts by Jan, Christophe, Stefanie, and Jay.

---

Django Fellows Update

Fellow Report - Natalia

Another busy week triaging six tickets, reviewing six more, security reports, meetings, and discussions around the recent DEP 20.

Fellow Report - Sarah

Finished up Navigator duties for Djangonauts, managed tickets and security work, and weighing in on anew-features suggestion for Django Admin actions configurable as buttons.

Fellow Report - Jacob

A four day week after returning from DjangoCon yielded some wins like merging @annalauraw's work on improved blank choice labels in forms and @rodbv's work on truncating huge deletion confirmation pages in the admin.

---

Podcasts

Django Chat #201: DjangoCon Europe Recap + Other News - Jeff Triplett

Jeff is President of the Django Software Foundation and a partner at REVSYS. We discuss the recently held DjangoCon Europe conference, existing Django news, and then share notes on current AI-powered workflows. Also available in video format on YouTube.

---

Events

DjangoCon US Sponsorship Opportunities

DjangoCon US is August 24-28 this year in Chicago. There are still sponsorship opportunities available (hint, hint) for any companies that want to participate.

EuroPython 2026 tickets now available

This year's conference is in Krakow, Poland from July 13-19, covering two days of tutorials, three days of talks, and two days of sprints.

Django Day Copenhagen Tickets Available

This event is October 2nd and early bird tickets are now available. Note that the event can sell out due to the size of the venue.

PyCon US 2026 - How to Convince Your Boss

PyCon US is fast approaching. If you and your colleagues want to attend, we have a short template to help you discuss the conference at work.

Django London Meetup

Two talks at this event May 7th at Kraken Tech: a talk by Paolo Melchiorre on Django's GeneratedField and Django in the Lab by Andy Woods.

---

Projects

jsheffie/django-schematic

An interactive graph of your Django model structure. With related blog post.

The Fixi Project

From the creator of HTMX, a collection of five small web libraries based on other libraries they work on. See the related website for more information.

01 May 2026 3:00pm GMT

News

PyCharm Campaign Now Includes RENEWALS!

Past or current PyCharm Pro users can now take part in the PyCharm campaign! Add 12 months to your current PyCharm Pro subscription. The same deal applies to past, current, or first time users. Get PyCharm Pro 30% off and 100% goes directly to the DSF! Until May 3rd.

Adopt Annual Release Cycle (DEP 20)

A new DEP from Carlton Gibson proposing that Django move to an annual release cycle. There is a lengthy discussion on the GitHub ticket

What's new in pip 26.1 - lockfiles and dependency cooldowns!

A detailed post of new features from Richard Si, the current maintainer, including pylock files, dependency cooldowns, security fixes, and more.

---

Django Software Foundation

It's time to redesign djangoproject.com

A redesign of the djangoproject.com website is in progress. This post from the Django blog is an update on the project's process: the plan, who's doing the work, and how you can help.

---

Updates to Django

Today, "Updates to Django" is presented by Hwayoung from Djangonaut Space! 🚀

Last week we had 14 pull requests merged into Django by 13 different contributors - including a first-time contributor! Congratulations to Dinesh Thumma for having their first commits merged into Django - welcome on board!

All release note-related changes this week came from Djangonaut Space. 🚀

• Added ModelAdmin.delete_confirmation_max_display option to truncate the list of related objects on the delete confirmation page in django/contrib/admin/options.py, added in Django 6.1 (#10109).
• Fixed the inaccessible "---------" blank choice label in form <select> controls by replacing it with "- Select an option -" via a new BLANK_CHOICE_LABEL setting in django/conf/global_settings.py, added in Django 6.1, and deprecated BLANK_CHOICE_DASH (#35879).

---

Sponsored Link

---

Articles

Running from Django's main development branch in production

Carlton Gibson makes the case for running Django off of Django's main development branch rather than waiting for security and feature releases.

Before GitHub

Armin Ronacher, of Flask and other open-source Python fame, looks wistfully at GitHub's decline and points out that Open Source did not always work this way.

Leaving GitHub as a Social Network

David Guillot points out the many red lines that Microsoft has recently crossed and debates other alternatives.

pgBackRest is dead. Now what?

One of several posts on the longtime sole maintainer of pgBackRest stepping away. This is a fundamental tool for PostgreSQL and a general failure in the open source ecosystem. Additional posts by Jan, Christophe, Stefanie, and Jay.

---

Django Fellows Update

Fellow Report - Natalia

Another busy week triaging six tickets, reviewing six more, security reports, meetings, and discussions around the recent DEP 20.

Fellow Report - Sarah

Finished up Navigator duties for Djangonauts, managed tickets and security work, and weighing in on anew-features suggestion for Django Admin actions configurable as buttons.

Fellow Report - Jacob

A four day week after returning from DjangoCon yielded some wins like merging @annalauraw's work on improved blank choice labels in forms and @rodbv's work on truncating huge deletion confirmation pages in the admin.

---

Podcasts

Django Chat #201: DjangoCon Europe Recap + Other News - Jeff Triplett

Jeff is President of the Django Software Foundation and a partner at REVSYS. We discuss the recently held DjangoCon Europe conference, existing Django news, and then share notes on current AI-powered workflows. Also available in video format on YouTube.

---

Events

DjangoCon US Sponsorship Opportunities

DjangoCon US is August 24-28 this year in Chicago. There are still sponsorship opportunities available (hint, hint) for any companies that want to participate.

EuroPython 2026 tickets now available

This year's conference is in Krakow, Poland from July 13-19, covering two days of tutorials, three days of talks, and two days of sprints.

Django Day Copenhagen Tickets Available

This event is October 2nd and early bird tickets are now available. Note that the event can sell out due to the size of the venue.

PyCon US 2026 - How to Convince Your Boss

PyCon US is fast approaching. If you and your colleagues want to attend, we have a short template to help you discuss the conference at work.

Django London Meetup

Two talks at this event May 7th at Kraken Tech: a talk by Paolo Melchiorre on Django's GeneratedField and Django in the Lab by Andy Woods.

---

Projects

jsheffie/django-schematic

An interactive graph of your Django model structure. With related blog post.

The Fixi Project

From the creator of HTMX, a collection of five small web libraries based on other libraries they work on. See the related website for more information.

01 May 2026 3:00pm GMT

I always thought it would be fun to create my own open source libraries or applications and distribute them somehow. When I started writing my book, Creating TUI Applications with Textual and Python, I took the plunge and wrote a helper package called textual-cogs, which is a collection of reusable dialogs and widgets for Textual. Right now, it is mostly just dialogs, but I do hope to add some widgets to it as well.

Anyway, I have released two new dialogs in the past week, with one in v0.0.4 and the other in v0.0.5.

A Textual Directory Dialog

In v0.0.5, I added a directory dialog similar to wxPython's wx.DirDialog. The dialog will display the user's directories and allow the user to choose one. It will also allow the user to create a new folder.

Here's a screenshot:

A Textual Open File Dialog

In v0.0.4, I also added an open file dialog. Textual cogs already has a save file dialog, and I had meant to include the open file dialog originally, but only recently got it added.

Here is what that looks like:

How to Install textual-cogs

You can install textual-cogs using pip or uv:

python -m pip install textual-cogs

Where to Get textual-cogs

You can find textual-cogs on the following websites:

• GitHub
• Python Packaging Index

The post Textual-cogs 0.0.5 Released appeared first on Mouse Vs Python.

01 May 2026 2:58pm GMT

In this quiz, you'll test your understanding of The Factory Method Pattern and Its Implementation in Python.

Factory Method is one of the most widely used design patterns, and it's a powerful tool for separating object creation from object use in your code.

By working through this quiz, you'll revisit the components of the pattern, recognize opportunities to apply it, and see how you can implement a reusable, general-purpose solution in Python.

---

[ Improve Your Python With 🐍 Python Tricks 💌 - Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

01 May 2026 12:00pm GMT

This week is a short detour from the normal technical topics I cover around Django, so feel free to skip if this isn't your thing!

Two big items this week, first up is that we launched Hamilton Rock this week! The next few months we will doing a private beta with select customers to test the system is working and get feeback about what's missing and needs more work. This is essential to us get some funding and finding where we are in product market fit!

Next up is that I will be mentoring Praful Gulani through Google Summer of Code this year on adding Experimental APIs to Django. I'm excited and nervous about this as it could have a fairly large impact on Django's trajectory, assuming we crack it and get the shape of this process and API correct. I am also hopeful to secure a new client in the next couple weeks which will address my immediate cashflow issues in the business.

In other news I'm working on a number of side projects. First up is Django Bureau and allpacked.co.uk. This is an experiment in getting AI agents to run an e-commerce store in an autonomous manner without much of my input, or at least that's the immediate goal. This will also have the side benefit of giving me greater understanding of our customers for Hamilton Rock.

Comfort Monitor Live has some updates coming in the pipeline which have developed much quicker thanks to Claude Code. Again with Claude I hope to do some concrete marketing in the near future, which will hopefully result in some revenue.

After the conversations and talk and DjangoCon Europe I have some renewed energy to put into django-prodserver, mainly around improving the API and shifting the development forward to a stable state.

Finally I have also forked a project from my church which is a Django backend for a virtual prayer/praise wall. I'm developing it into a more generic project that could suit more online communities, adding a few new feature ideas I have and perhaps exploring the idea of it being federated.

I do have other projects in the works, but they are lower down the list of priorites so the above need to get to a satisfactory place before I move on... or at least that's the idea, I was getting overwhelmed with the number of ideas/projects in my head so hopefully this is more managable!

I'm also wanting to blog about my adventures with neapolitan and pushing Django templates in new ways (again this required time I don't have much of!)

01 May 2026 5:00am GMT

Here is a useful trick that is unreasonably effective for simple computer use goals using modern terminal agents. On macOS, there has been a terminal osascript command since the original release of Mac OS X. All you have to do is suggest your agent use it and it can perform any application control action available in any AppleScript dictionary for any Mac app. No MCP set up or tools required at all. Agents are much more adapt at using rod terminal commands, especially ones that haven't changed in 30 years. Having a computer control interface that hasn't changed in 30 years and has extensive examples in the Internet corpus makes modern models understand how to use these tools basically Effortlessly. macOS locks down these permissions pretty heavily nowadays though, so you will have to grant the application control permission to terminal. But once you have done that, the range of possibilities for commanding applications using natural language is quite extensive. Also, for both Safari and chrome on Mac, you are going to want to turn on JavaScript over AppleScript permission. This basically allows claude or another agent to debug your web applications live for you as you are using them.In chrome, go to the view menu, developer submenu, and choose "Allow JavaScript from Apple events". In Safari, it's under the safari menu, settings, developer, "Allow JavaScript from Apple events". Then you can do something like "Hey Claude, would you Please use osascript to navigate the front chrome tab to hacker news". Once you suggest using OSA script in a session it will figure out pretty quickly what it can do with it. Of course you can ask it to do casual things like open your mail app or whatever. Then you can figure out what other things will work like please click around my web app or check the JavaScript Console for errors. Another very important tips for using modern agents is to try to practice using speech to text. I think speaking might be something like five times faster than typing. It takes a lot of time to get used to, especially after a lifetime of programming by typing, but it's a very interesting and a different experience and once you have a lot of practice It starts to to feel effortless.

04 Apr 2026 1:31pm GMT

I have been using macOS voice control for about three years. First it was a way to reduce pain from excessive computer use. It has been a real struggle. Decades of computer use habits with typing and the mouse are hard to overcome! Text selection manipulation commands work quite well on macOS native apps like apps written in swift or safari with an accessibly tagged webpage. However, many webpages and electron apps (Visual Studio Code) have serious problems manipulating the selection, not working at all when using "select foo" where foo is a word in the text box to select, or off by one errors when manipulating the cursor position or extending the selection. I only recently expanded my repertoire with the "start drag" and "drop" commands, previously having used "Click and hold mouse", "move cursor to x", and "release mouse". Well, now I have discovered that using "start drag x" and "drop x" makes a fantastic text selection method! This is really going to improve my speed. In the long run, I believe computer voice control in general is going to end up being faster than WIMP, but for now the awkwardly rigid command phrasing and the amount of times it misses commands or misunderstands commands still really holds it back. I've been learning the macOS Voice Control specific command set for years now and I still reach for the keyboard and mouse way too often.

16 Mar 2026 11:04am GMT

Humans Are Bad At Perceiving

Humans are not particularly good at catching bugs. For one thing, we get tired easily. There is some science on this, indicating that humans can't even maintain enough concentration to review more than about 400 lines of code at a time..

We have existing terms of art, in various fields, for the ways in which the human perceptual system fails to register stimuli. Perception fails when humans are distracted, tired, overloaded, or merely improperly engaged.

Each of these has implications for the fundamental limitations of code review as an engineering practice:

• Inattentional Blindness: you won't be able to reliably find bugs that you're not looking for.

• Repetition Blindness: you won't be able to reliably find bugs that you are looking for, if they keep occurring.

• Vigilance Fatigue: you won't be able to reliably find either kind of bugs, if you have to keep being alert to the presence of bugs all the time.

• and, of course, the distinct but related Alert Fatigue: you won't even be able to reliably evaluate reports of possible bugs, if there are too many false positives.

Never Send A Human To Do A Machine's Job

When you need to catch a category of error in your code reliably, you will need a deterministic tool to evaluate - and, thanks to our old friend "alert fatigue" above - ideally, to also remedy that type of error. These tools will relieve the need for a human to make the same repetitive checks over and over. None of them are perfect, but:

• to catch logical errors, use automated tests.
• to catch formatting errors, use autoformatters.
• to catch common mistakes, use linters.
• to catch common security problems, use a security scanner.

Don't blame reviewers for missing these things.

Code review should not be how you catch bugs.

What Is Code Review For, Then?

Code review is for three things.

First, code review is for catching process failures. If a reviewer has noticed a few bugs of the same type in code review, that's a sign that that type of bug is probably getting through review more often than it's getting caught. Which means it's time to figure out a way to deploy a tool or a test into CI that will reliably prevent that class of error, without requiring reviewers to be vigilant to it any more.

Second - and this is actually its more important purpose - code review is a tool for acculturation. Even if you already have good tools, good processes, and good documentation, new members of the team won't necessarily know about those things. Code review is an opportunity for older members of the team to introduce newer ones to existing tools, patterns, or areas of responsibility. If you're building an observer pattern, you might not realize that the codebase you're working in already has an existing idiom for doing that, so you wouldn't even think to search for it, but someone else who has worked more with the code might know about it and help you avoid repetition.

You will notice that I carefully avoided saying "junior" or "senior" in that paragraph. Sometimes the newer team member is actually more senior. But also, the acculturation goes both ways. This is the third thing that code review is for: disrupting your team's culture and avoiding stagnation. If you have new talent, a fresh perspective can also be an extremely valuable tool for building a healthy culture. If you're new to a team and trying to build something with an observer pattern, and this codebase has no tools for that, but your last job did, and it used one from an open source library, that is a good thing to point out in a review as well. It's an opportunity to spot areas for improvement to culture, as much as it is to spot areas for improvement to process.

Thus, code review should be as hierarchically flat as possible. If the goal of code review were to spot bugs, it would make sense to reserve the ability to review code to only the most senior, detail-oriented, rigorous engineers in the organization. But most teams already know that that's a recipe for brittleness, stagnation and bottlenecks. Thus, even though we know that not everyone on the team will be equally good at spotting bugs, it is very common in most teams to allow anyone past some fairly low minimum seniority bar to do reviews, often as low as "everyone on the team who has finished onboarding".

Oops, Surprise, This Post Is Actually About LLMs Again

Sigh. I'm as disappointed as you are, but there are no two ways about it: LLM code generators are everywhere now, and we need to talk about how to deal with them. Thus, an important corollary of this understanding that code review is a social activity, is that LLMs are not social actors, thus you cannot rely on code review to inspect their output.

My own personal preference would be to eschew their use entirely, but in the spirit of harm reduction, if you're going to use LLMs to generate code, you need to remember the ways in which LLMs are not like human beings.

When you relate to a human colleague, you will expect that:

1. you can make decisions about what to focus on based on their level of experience and areas of expertise to know what problems to focus on; from a late-career colleague you might be looking for bad habits held over from legacy programming languages; from an earlier-career colleague you might be focused more on logical test-coverage gaps,
2. and, they will learn from repeated interactions so that you can gradually focus less on a specific type of problem once you have seen that they've learned how to address it,

With an LLM, by contrast, while errors can certainly be biased a bit by the prompt from the engineer and pre-prompts that might exist in the repository, the types of errors that the LLM will make are somewhat more uniformly distributed across the experience range.

You will still find supposedly extremely sophisticated LLMs making extremely common mistakes, specifically because they are common, and thus appear frequently in the training data.

The LLM also can't really learn. An intuitive response to this problem is to simply continue adding more and more instructions to its pre-prompt, treating that text file as its "memory", but that just doesn't work, and probably never will. The problem - "context rot" is somewhat fundamental to the nature of the technology.

Thus, code-generators must be treated more adversarially than you would a human code review partner. When you notice it making errors, you always have to add tests to a mechanical, deterministic harness that will evaluates the code, because the LLM cannot meaningfully learn from its mistakes outside a very small context window in the way that a human would, so giving it feedback is unhelpful. Asking it to just generate the code again still requires you to review it all again, and as we have previously learned, you, a human, cannot review more than 400 lines at once.

To Sum Up

Code review is a social process, and you should treat it as such. When you're reviewing code from humans, share knowledge and encouragement as much as you share bugs or unmet technical requirements.

If you must reviewing code from an LLM, strengthen your automated code-quality verification tooling and make sure that its agentic loop will fail on its own when those quality checks fail immediately next time. Do not fall into the trap of appealing to its feelings, knowledge, or experience, because it doesn't have any of those things.

But for both humans and LLMs, do not fall into the trap of thinking that your code review process is catching your bugs. That's not its job.

Acknowledgments

Thank you to my patrons who are supporting my writing on this blog. If you like what you've read here and you'd like to read more of it, or you'd like to support my various open-source endeavors, you can support my work as a sponsor!

04 Mar 2026 5:24am GMT

We saw that cookieplone was coming up, and Docker, and as game changer uv making the installation of Python packages much faster.

With cookieplone you get a monorepo, with folders for backend, frontend, and devops. devops contains scripts to setup the server and deploy to it. Our sysadmins already had some other scripts. So we needed to integrate that.

First idea: let's fork it. Create our own copy of cookieplone. I explained this in my World Plone Day talk earlier this year. But cookieplone was changing a lot, so it was hard to keep our copy updated.

Maik Derstappen showed me copier, yet another templating language. Our idea: create a cookieplone project, and then use copier to modify it.

What about the deployment? We are on GitLab. We host our runners. We use the docker-in-docker service. We develop on a branch and create a merge request (pull request in GitHub terms). This activates a piple to check-test-and-build. When it is merged, bump the version, use release-it.

Then we create deploy keys and tokens. We give these access to private GitLab repositories. We need some changes to SSH key management in pipelines, according to our sysadmins.

For deployment on the server: we do not yet have automatic deployments. We did not want to go too fast. We are testing the current pipelines and process, see if they work properly. In the future we can think about automating deployment. We just ssh to the server, and perform some commands there with docker.

Future improvements:

• Start the docker containers and curl/wget the /ok endpoint.
• lock files for the backend, with pip/uv.

22 Jan 2026 9:43am GMT

This is a talk about migrating from Plone 4 to 6 with the newest toolset.

There are several challenges when doing Plone migrations:

• Highly customized source instances: custom workflow, add-ons, not all of them with versions that worked on Plone 6.
• Complex data structures. For example a Folder with a Link as default page, with pointed to some other content which meanwhile had been moved.
• Migrating Classic UI to Volto
• Also, you might be migrating from a completely different CMS to Plone.

How do we do migrations in Plone in general?

• In place migrations. Run migration steps on the source instance itself. Use the standard upgrade steps from Plone. Suitable for smaller sites with not so much complexity. Especially suitable if you do only a small Plone version update.
• Export - import migrations. You extract data from the source, transform it, and load the structure in the new site. You transform the data outside of the source instance. Suitable for all kinds of migrations. Very safe approach: only once you are sure everything is fine, do you switch over to the newly migrated site. Can be more time consuming.

Let's look at export/import, which has three parts:

• Extraction: you had collective.jsonify, transmogrifier, and now collective.exportimport and plone.exportimport.
• Transformation: transmogrifier, collective.exportimport, and new: collective.transmute.
• Load: Transmogrifier, collective.exportimport, plone.exportimport.

Transmogrifier is old, we won't talk about it now. collective.exportimport: written by Philip Bauer mostly. There is an @@export_all view, and then @@import_all to import it.

collective.transmute is a new tool. This is made to transform data from collective.exportimport to the plone.exportimport format. Potentially it can be used for other migrations as well. Highly customizable and extensible. Tested by pytest. It is standalone software with a nice CLI. No dependency on Plone packages.

Another tool: collective.html2blocks. This is a lightweight Python replacement for the JavaScript Blocks conversion tool. This is extensible and tested.

Lastly plone.exportimport. This is a stripped down version of collective.exportimport. This focuses on extract and load. No transforms. So this is best suited for importing to a Plone site with the same version.

collective.transmute is in alpha, probably a 1.0.0 release in the next weeks. Still missing quite some documentation. Test coverage needs some improvements. You can contribute with PRs, issues, docs.

22 Jan 2026 9:43am GMT

This is a talk I did not want to give.

I am team lead of the Plone Admin team, and work at kitconcept.

The current state: see the keynotes, lots happening on the frontend. Good.

The current state of our IT: very troubling and daunting.

This is not a 'blame game'. But focussing on resources and people this conference should be a first priority. We are a real volunteer organisation, nobody is pushing anybody around. That is a strength, but also a weakness. We also see that in the Admin team.

The Admin team is 4 senior Plonistas as allround admin, 2 release managers, 2 CI/CD experts. 3 former board members, everyone overburdened with work. We had all kinds of plans for this year, but we have mostly been putting out fires.

We are a volunteer organisation, and don't have a big company behind us that can throw money at the problems. Strength and weakness. In all society it is a problem that volunteers are decreasing.

Root causes:

• We failed to scale down in time in our IT landscape and usage.
• We have no clean role descriptions, team descriptions, we can't ask a minimum effort per week or month.
• The trend is more communication channels, platforms to join and promote yourself, apps to use.

Overview of what have have to keep running as admin team:

• Support main development process: github, CI/CD, Jenkins main and runners, dist.plone.org.
• Main communication, documentation: pone.org, docs.plone.org, training.plone.org, conf and country sites, Matomo.
• Community office automation: Google docds, workspacae, Quaive, Signal, Slack
• Broader: Discourse and Discord

The first two are really needed, the second we already have some problems with.

Some services are self hosted, but also a lot of SAAS services/platforms. In all, it is quite a bit.

The Admin team does not officially support all of these, but it does provide fallback support. It is too much for the current team.

There are plans for what we can improve in the short term. Thank you to a lot of people that I have already talked to about this. 3 areas: GitHub setup and config, Google Workspace, user management.

On GitHub we have a sponsored OSS plan. So we have extra features for free, but it not enough by far. User management: hard to get people out. You can't contact your members directly. E-mail has been removed, for privacy. Features get added on GitHub, and no complete changelog.

Challenge on GitHub: we have public repositories, but we also have our deployments in there. Only really secure would be private repositories, otherwise the danger is that credentials or secret could get stolen. Every developer with access becomes an attack vector. Auditing is available for only 6 months. A simple question like: who has been active for the last 2 years? No, can't do.

Some actionable items on GitHub:

• We will separate the contributor agreement check from the organisation membership. We create a hidden team for those who signed, and use that in the check.
• Cleanup users, use Contributors team, Developers
• Active members: check who has contributed the last years.
• There have been security incidents. Someone accidentally removed a few repositories. Someone's account got hacked, luckily discovered within a few hours, and some actions had already been taken.
• More fine grained teams to control repository access.
• Use of GitHub Discussions for some central communication of changes.
• Use project management better.
• The elephant in the room that we have practice on this year, and ongoing: the Collective organisation. This was free for all, very nice, but the development world is not a nice and safe place anymore. So we already needed to lock down some things there.
• Keep deployments and the secrets all out of GitHub, so no secrets can be stolen.

Google Workspace:

• We are dependent on this.
• No user management. Admins have had access because they were on the board, but they kept access after leaving the board. So remove most inactive users.
• Spam and moderation issues
• We could move to Google docs for all kinds of things. Use Google workspace drives for all things. But the Drive UI is a mess, so docs can be in your personal account without you realizing it.

User management:

• We need separate standalone user management, but implementation is not clear.
• We cannot contact our members one on one.

Oh yes, Plone websites:

• upgrade plone.org
• self preservation: I know what needs to be done, and can do it, but have no time, focusing on the previous points instead.

22 Jan 2026 9:43am GMT