I'm self-nominating for the inaugural Python Packaging Council. What I'd push for: aiming for good enough now and iterating on it rather than chasing perfection upstream, while not being afraid to say no, empathy for every use case, and compassion for the people doing the work.
A partial standard that lands this year and gets revisited or extended in two years beats a complete one still sitting in draft in 2030. A few review rounds are required, but I'd like to avoid stalling progress due to PEPs that spend forever in back-and-forth review chasing perfection from day one. I find it important to create extendable standards: start generic and high level, then optimize later by filling in the blanks. That doesn't mean saying yes to everything. Knowing when to say no matters just as much. This body has a veto and it'll need it, and a clear no is a service: it lets someone stop or come back with something better.
The first job is working out how this Council runs: how things reach us, how we take input, what we publish when we decide, how we hand over to whoever comes next. I want the rules we write to include the ecosystems that don't share our toolchain. Scientific and compiled builds, conda, distro packagers, mobile and embedded, internal mirrors. Each has constraints the others don't, and a process built around pure Python on PyPI keeps producing standards that fit none of them. They should be in the room while something gets designed, not handed a comment period once it's settled. And I want it democratic rather than convenient. Decisions in the open, positions on record, a way for anyone to put something in front of us without knowing one of us personally, and a written answer to who we report to and how we can be removed. We should aim to give anyone interested the opportunity to participate in the process.
Empathy, because the scientist with a compiled dependency, the team behind a corporate proxy and the person shipping to a phone don't want the same things, and a standard that looks obvious from inside one of those worlds is unworkable in another. Anything reaching us should say who it hurts as well as who it helps. Where that isn't clear, helping the author go and find out is our job, not a mark against them. Compassion, because a lot of this is unpaid and the people doing it soak up the frustration of users who can't see what they're dealing with. Most of what we decide lands on someone who implements it in their evenings. Before we approve something we should know who that someone is and whether they've said yes.
A bit about myself. I'm the primary maintainer of virtualenv, build, python-discovery, tox, pipx, filelock and platformdirs. I've been a PSF Fellow since 2021. I work at Bloomberg on the Developer Experience team, doing artifact repository hosting. That job pays for some of my open source time. I'm based in Los Angeles, USA. I wrote PEP 662, which was rejected in favour of PEP 660. I write at bernat.tech, including a recap of this year's Packaging Summit. PEP 662 is the bit worth knowing. I argued editable installs belonged in the frontend, a competing proposal put them in the backend, and 660 won. I'd still make the same case today. Having an answer mattered more than me being right.