[Feedback requested!] What’s next for the Python and PSF Wiki?

PSF
1

Hi folks-

As you may have noticed, the Python and PSF Wiki was closed for new edits (somewhat unceremoniously) in February 2026 due to excessive automated traffic and security concerns on outdated infrastructure. We realize this wasn’t the best approach, and we apologize for any inconvenience or disrupted processes.

Since getting through PyCon US 2026 and various other projects, PSF Staff now have some capacity to address the wiki situation moving forward. So far, we’ve spent some time discussing our options, understanding usage, researching platforms, and experimenting a little with what the wiki could look like in the future.

We took a look at available stats on usage for the wiki. The wiki still gets traffic, but that traffic is concentrated on a small number of pages, most of which cover topics that have better, more maintained homes today. It’s also worth noting that a significant portion of this traffic appears to be automated crawler activity hitting routes that don’t exist or never existed, which means the real human readership is likely meaningfully lower than the raw numbers suggest.

Moving forward, the PSF would like to find a solution that gives us better quality control over content that represents the PSF, improves usability for staff who work in more familiar systems day-to-day, and makes security and access management more straightforward alongside our existing GitHub and python.org infrastructure. Ideally, we wouldn’t deploy a system that will require even more maintenance on PSF staff or relying solely on volunteers. Most other solutions we’ve found include deploying apps that run on other programming languages like PHP and would incur a heavier maintenance burden.

To be transparent, after several conversations, we’re genuinely unsure whether to retire the wiki and leave the archive standing or migrate it to a new place where it can continue to be updated and used. If we did archive it, we’d pull out important artifacts (like work group charters) to python.org. Part of figuring out the path forward is understanding how much the wiki is still being used, and for what.

So, based on all of this, we want to ask the community a couple of questions:

  • Are you aware of any content on the wiki that doesn’t exist anywhere else?

  • Are you actively referencing the wiki in your Python-related activities?

  • Do you run any work group or Python community related processes through the wiki?

  • If we migrate it, is anyone willing to help clean it up and then continue to maintain it?

We welcome your input on one or more of these questions, or just general thoughts about the pros/cons of the various wiki-related options available to our community moving forward :grinning_face:

11 Likes
2

One of the best features of the wiki was that it did NOT have such control. The entire point is that anyone can edit, without begging for permission.

1 Like
3

Jacob’s phrase wasn’t “control”, it was “quality control”. I think if information is on a PSF-hosted domain, we should have some idea about what level of quality we are claiming for it, and how we will reach that level.

12 Likes
4

The wiki’s level of quality was always “whatever people are willing to work on”. If someone thinks a page isn’t good enough, they can improve it; but nobody is going through saying “that page needs to be deleted because it’s not good enough/outdated/etc”.

We already have the documentation pages where someone maintains full quality control. The wiki was a different place, managed by community editors and not centralized.

Maybe the PSF doesn’t want that any more, but I think that that is something of value.

3 Likes
5

But I think the question is enough people putting in that effort to warrant keeping it around as it isn’t free to run that infrastructure.

2 Likes
6

Yep. If that’s the issue, then shutting it down will be the thing, but I don’t see that the PSF taking control of it is going to help anything. It would have been nice if the wiki maintainers had been contacted about the shutdown before it happened though.

2 Likes
7

I’ve been helping with the maintenance of the wiki system for many years (since the attack in 2013, when I helped to restore the content) and worked on making sure that it keeps running, even though it’s a very old system.

A small team of volunteers on pydotorg-www helped gateway edit access to it due to the huge increase in spam after 2013 and having human interaction to get edit access turned out to be great helper in getting spam to a low level again.

The shutdown was indeed not done well. It lacked communication, was one sided and put in place without even discussing other options. Neither the team nor I were informed beforehand.

To answer some of your questions:

  • yes, I have been running the Python events team and submissions via the wiki
  • I also maintained the list of current Python conferences in the wiki
  • many training providers used the wiki to advertise their trainings
  • many book authors published links to their books on the wiki (including sponsors of the PSF)
  • quite a few people had their own wiki homepage on the wiki
  • the content may be old in many areas, but a lot of it is still valid and not found elsewhere
  • the wiki also holds a great deal of Python history, since it was, for a long time one of the main information resources the Python community had to put hints and additional documentation for Python - this was before other public resources became available and Python became one of the most used programming languages on the planet
  • it should also be noted that the content is not owned by the PSF - the content is free to use by anyone and essentially “owned” by the community

FWIW, I am no longer willing to help maintain the wiki on behalf of the PSF. Instead, I plan to create and run a new instance, using the existing content, but on a different, more modern technology stack and then invite people to become editors. Hopefully, some of the existing team from pydotorg-www will join in and help with this. I would certainly welcome them.

Perhaps this will become a true community resource again. But even if not, I want to enable people who have edited the content in the past to still be able to fix and correct their pages - or delete their traces if they so desire.

Stay tuned.

12 Likes
8

I would be happy to join you on that project.

2 Likes
9

Hopefully there are some gems on it, but I never even noticed the shutdown. I’ve never found the wiki to be up to date, and personally have never found anything useful on it. I’ve never once recommended it.

If others gain value from it, and find contributing is not futile, then that’s fantastic. But in general both the CPython docs, and the packaging, typing and developer guides, are all really good. They should be the single source of truth.

Don’t put too much work into the wiki on my account - treat it as a legacy commitment.

3 Likes
10

One page in the wiki that I think should be in the docs is Time Complexity. It seems like important information about CPython and should be documented.

15 Likes
11

Thank you for opening this discussion and for gathering feedback from the community.

I agree that the wiki had significant problems. Much of the content was outdated, navigation was difficult, and the architecture made it hard for people to contribute or even update basic information.

The Diversity and Inclusion Work Group experienced this too. For example, we were not able to update the list of elected members easily. This is important not only for accuracy, but also for making sure volunteers receive proper credit for their work.

I can understand why retiring the wiki seemed like a reasonable response. Maintaining a system that was difficult to use and update, with unclear levels of activity, raised reasonable questions about its future. I do not believe the intention was to disregard the people who had contributed to or maintained it over the years.

At the same time, I understand the concerns raised here by @malemburg about the process. The disagreement does not seem to be mainly about whether the wiki needed to change. Most of us appear to agree that it did. The concern is whether the people who had maintained and relied on it had enough opportunity to be part of the discussion before it was retired.

I think both things can be true. The wiki was no longer working well for many of us, and the process could have included more consultation.

As a PSF board member and the D&I WG member, I also think inclusion in decisions like this is increasingly important. The PSF supports work groups and communities across many countries and regions, and the systems that represent their work should allow those communities to participate in maintaining them.

I believe a collaborative platform where work groups can maintain their own charters, membership information, meeting notes, and documentation would be extremely useful.

There may also be two different needs to consider.

  • Community-maintained Python content needs openness and low barriers to contribution.
  • Official PSF documentation needs accuracy, accountability, and clear ownership.

These may not need to live in exactly the same place, but I think they should be clearly connected so that we do not create even more fragmentation or make information harder to find for the community.

Alongside gathering feedback from the broader community, would it also make sense to consult the PSF work groups directly about what information they need to maintain and what contribution process would work for them?

That would help us decide not only where the existing content should move, but also how contributors and work groups should be able to maintain it in the future.

I would really prefer that we find a collaborative and amicable path forward that recognises the problems with the old system, the difficulty of the decision, and honors the work of the volunteers who supported the wiki for many years.

7 Likes
12

Does content from Workgroups need to be in a form of a wiki? Can it be a github pages, static pages, markdown rendered websites? For example, Python docs editorial board publishes our meeting notes, decisions, and list of board members on a static site on GitHub pages. This is markdown based content.

Github repo at GitHub - python/editorial-board: Communications of the Python Documentation Editorial Board · GitHub

The things that Marc andre mentioned: do those need to be hosted in PSF infrastructure? It sounds like people have been using PSF infrastructure wiki page as an advertising platform for free. To me it is even more the case that PSF should be able to curate and manage the content hosted on wiki/their own infra to ensure alignment with PSF mission, instead of whatever goes. Advertising should be a paid feature.

6 Likes
Links to personal blogs in docs
13

(I’m part of PSF but had no part in the wiki shutdown or related discussions. I don’t have insider info on this & I’m speaking for myself.)

No. I strongly disagree. Suddenly shutting down/archiving a wiki without consulting its admins would not be a reasonable response to outdated content and difficult navigation. If that was the reason, the wiki should be restored immediately, with an apology.
It’s clear that you want the wiki to be something else – and you’re not alone – but just shutting it down was not OK.

As far as I know, the reason was that wiki started getting mass-scraped, like every public page nowadays. The system burned CPU time (I imagine there are real costs to serving bots that will mindlessly ask for all possible history diffs), while the site wasn’t responsive for regular human users anyway (this I did experience). So it was shut down, an apology was given (perhaps not properly), but the wiki can’t be brought back online on the old platform.
Is that correct?

Well, that sounds like a reasonable list of features for a site the PSF would run?
As I read it, “better quality control over content that represents the PSF” could be something like a line saying “this does not represent the PSF; anyone can edit” on the wiki pages.
But yeah, moving away from PSF & python.org looks like a good option too – that’s the best way to make it exactly your flavour of true community resource. Decentralization FTW :‍)

8 Likes
14

The stale content was not really a factor in shutting it down.. it was the consistent pages at 3am because a bot or bad actor found a new way around rate limiting or safeguards and the service continually crashed.

I ack my approach caused harm, and as we go forward I really hope to find a better solution for all of us. I’m truly regretful that my abrupt action caused undue stress to folks in the community that have been working on this for quite some time, often tirelessly and thanklessly. That was not my intention.

I don’t wish for any splintering to occur and have information in various places but I also stand behind the desire to see quality control when it comes to any public-facing PSF content that represents us to community members and sponsors.

I’ve been experimenting with moving the entirety of the wiki into git which could afford us the same level of “allowing anyone to edit” through the form of pull requests and eventually write access on the repo. This exploration is my effort to find a solution that won’t require spinning up obscure PHP or Javascript services that the PSF infra team would then have to support for the next 20 years.

I didn’t lead with a detailed description of that exploratory work because it felt important to get input on future solutions- as I turned off the service, I also didn’t want to just turn something new on without connecting with the community.

2 Likes
15

We already have that for the documentation repo. How would anything else be better? It’s still “beg for someone to decide that your change is worthwhile” rather than actually letting the community make edits.

I would love for a magical way for there to be no malicious edits. But a wiki should at least feel like it’s open for anyone to edit. Barriers to entry need to feel reasonable (like “you need to sign up and prove you’re a person”, not “you need to convince three core devs, seven dwarves, and nine mortal men doomed to die”) and ideally should be barriers to people, not to individual changes. I don’t know how that could be achieved while gatekeeping everything in that way.

4 Likes
16

Shifting to git would likely be a barrier to broader participation just from a technical perspective. There are lots of people who know enough to edit a wiki page but are uncomfortable with or even entirely unaware of git, let alone the process of submitting a PR. I agree with @rosuav that moving in this direction would make it less clear what the distinction is between the wiki and the docs. In my view the point of something like a wiki is to cast a very broad net in terms of who may contribute. Not so broad that it allows spam, bots, or total nonsense, but broad enough that it does allow random people have some tidbits of Python knowledge to share. That latter set of people is far larger than the set of people who are prepared to submit a Github PR.

2 Likes
17

Fair correction and thank you,@encukou. I can see that my wording brought two separate issues together and gave the impression that the outdated content and usability problems made the abrupt shutdown reasonable. That is not what I meant, and I should have expressed the distinction more clearly.

The content, navigation, and contribution problems were reasons to reconsider the longer-term future of the wiki. They were not, by themselves, reasons to disable editing without involving the people who maintained it.

@JacobCoffee has clarified that the immediate action was taken because repeated automated traffic was causing the service to fail. I understand that the immediate technical response and the longer-term decision about the wiki’s future are two different things.

I agree that the maintainers should have been informed as soon as possible and included before any longer-term decisions were made about retiring, replacing, or migrating the wiki.

I appreciate Jacob acknowledging the harm caused by the abrupt approach, and definitely appreciate all the maintainers like @malemburg explaining the work, history, and community processes that depended on the wiki.
This was not simply a technical platform. It represented many years of volunteer work and accumulated community knowledge, so I understand why people were deeply upset.

My intention was not to excuse the lack of communication or to turn this into a question of one person’s intentions. I was trying to recognise both the infrastructure problem and its impact on the volunteers involved.
Acknowledging that impact is part of moving forward. The question now is how we work together on the future of the content, its governance, and the participation of the communities involved, without repeating the same communication and consultation gap.

Hope this feedback helps us shape a better solution.

4 Likes
18

Hello Brendan, I wanted to share something on this topic, regarding a similar situation around the documentation translation. As you might know, there are plenty of languages that are using transifex, a great tool to help online with the translations, however a couple of languages, including the one I was working on, decided to keep using Git for such process. The outcome was very positive, and many people has been thanking the group because they managed to Learn how to use Git and at the same time, they did a contribution to the community. This case is still the only reason on why we keep using Git and haven’t moved to transifex. Of course, each situation is different, but considering that people can also “edit + submit PR” using the Github UI, I don’t think there is a real risk here, and in the case we do have people not knowing how to do an edit/PR we can have a small group of people willing to help. I’d be more than happy to join that group!

4 Likes
19

I completely agree with this statement, I think WG should have their own ways of documenting things and have their activities, and I’m very happy to see how the editorial board does it. A couple of time I have suggested that such approach should be replicated in other WGs.

I can confirm this, you have been very helpful to me (Thank you!) the couple of times I had troubles trying to login, or I didn’t have permissions to edit certain pages. I know first hand how tricky is to maintain a wiki, and how easily things can needs some immediate reaction.

–

Now, Keeping a wiki up-to-date is a very time consuming task, and even thought I’m thankful for all the volunteers maintaining it, I ended up finding outdated things in different sections, I think I might have manage to update only a few pages, but IMHO considering the new tools/platforms we have around to keep this type of information, even plain markdown files in a repository would be simpler, and even though a wiki can also keep track of differences between versions, it might be simpler to have those changes visible in a Git repository. I know I’m very bias, since I have been moving away from wikis for a long time, but I don’t see a downside of moving the critical content to a simple repository, and visualize that with any existing tool.

A very personal problem I had with the wiki, was that it was duplicating a lot of content, as described in this thread, like conferences, communities, working groups, list of references, etc, that in my opinion deserve a more prominent place to be hosted, like a documentation page maintained by the community, whatever new solution can have dedicated and more organized sections for people to add their trainings, books, etc.

I do agree the wiki has been a very critical part of Python’s development through the past years, but in my personal bubble, I have been only hearing that “it’s outdated”, “it looks old”, "login doesn’t work, and many other comments, that maybe are related to generational gaps on how we consume information, or what people expect.

This is purely my opinion, and I hope not to open a new can of worms, but I would love to see the PSF-related information from python.org and all the pieces from the wiki.qt.io that are relevant (WGs, communities, conferences, books, trainings, etc) into a real documentation page that could enable anyone to make suggestions, improve the content we have, and even open the doors to new initiatives to having a human-generated i18n for the website, and get into more people.

4 Likes
20

You could outsource infrastructure, accounts, visual design, and in part spam control to GitHub by migrating to a GitHub wiki. It would increase centralization and force a switch from Moin wiki markup to Markdown or reStructuredText. Some advanced features, like transclusion, wouldn’t be available. Further migration would be easier because other wiki engines try to be compatible with GitHub wikis.

1 Like