Question: Is there a canonical repo for pre-governance and pre-PEP discussions and drafts?

Is there a repo that PyPA uses for governance related discussions, capturing Packaging Summit links/discussions, and pre-PEP related discussions?

No. The de facto place for these discussions are here on Discourse.

Is this repo the place for that? GitHub - pypa/ Source code for the website


I don’t think that the repo would be the place as seems more like end-user and developer documentation. is focused on being an end user guide.

I ask because it’s difficult to follow the long threads here and curate what may be good topics for the next PyCon Packaging Summit.

Long threads are an acknowledged problem. Having a community manager could help with curation. Having a newsletter, as suggested earlier by Pradyun, could be helpful but requires time and effort to achieve.

As for the Packaging Summit, the current process is for people to propose talks, somewhat similar to CPython Lang Summit. There is some interest to provide a better mechanism for active contributors who are unable to attend in person to participate.

My 2 cents (and that may be all that it is worth) is that it is difficult to reason about future governance and community priorities without a canonical place to do so. If there is such a canonical place, I think we should be more explicit and communicate it more widely.

P.S. As always, thank you for all who contribute their time to the packaging ecosystem. We likely don’t share our appreciation enough, and this is a difficult, complex area where core maintainers deserve gratitude and constructive discussion.


I suppose this repo is a place for problems: Issues · pypa/packaging-problems · GitHub

I have a long flight in a few weeks if you want some help curating/labeling these issues here.

I don’t think such a thing exists. That repo is not “official” more like someone’s effort. In practice these discussions and draft happen here and drafts are shared in form of PRs against the peps repo.


To preface, I have no “authority” in the PyPA myself, and have been less actively involved and following every thread and PEP lately than in the past couple years; these are just my personal impressions from my experience as a PEP author and editor, Discourse moderator, Packaging Summit organizer and discussion participant.

My understanding, both from experience and from updating the site accordingly, is that the canonical place for these discussions is this very Discourse category, rather than some GitHub repo.

This is where the site directs such discussions (aside from a few specific things, like votes, that AFAIK still happen on the PyPA-members-only mailing list), and in my experience is almost invariably where PEP ideas are born, governance changes are debated and where we post announcements, updates and followups from the packaging summit. Detailed point by point review of pre-PEP-drafts tends happen on users’ forks of the PEPs repo (or sometimes on the PEP repo PRs adding them, though we generally discourage that).

To help organize things further, we could implement a system of tags, category-level tags, or full subcategories, if there’s enough interest and consensus on what is desired.

That’s just the PyPA website. I would assume issues there would be primary related to its content and infrastructure, rather than broader discussions.

Right, that’s for the PyPUG specifically.

FWIW, at least for the past few years we’ve done it, our strategy here has been to have the summit attendees pitch topics they want to discuss, and at least during that period, we’ve been able to set the event length and schedule such that the number and variety of topics has been a pretty good match to the time available, with only relatively light-handed curation,

Speaking of which, we’ll probably get started organizing for that within the month or so, based on what we’ve done in previous years…so stay tuned!

This seems to be mostly used for end-user feedback nowadays, at least from my experience, aside from a few long-running issues/discussions.


That’s not how packaging summits work. They instead follow the same CPython summits do. Any conversation here without a person willing to present it (and submit it upfront) will not be really discussed. The agenda for the summit is driven by attendee’s presented topics (which need to be submitted a few weeks before). So if we’d like to discuss it at the summit, we need to find the person discussing here and nudge them to attend and present the topic.


Thanks, @CAM-Gerlach and @bernatgabor, for your helpful and detailed responses.

Hmmm… I’m looking to better understand how we can communicate more effectively and unburden maintainers from following long threads, especially if they haven’t followed the thread from the beginning. There seems to be a lot of duplication of effort which leads to more confusion and maintainer burnout.

I guess what I’m looking for is a place that makes “how to contribute” and “how to follow” packaging more welcoming, and less an odyssey of looking through a number of links to find the dispersed knowledge.


For example, there are now 146 posts about the PEP 735: Dependency Groups in pyproject.toml

That’s a large history to work through.

1 Like

Yeah, that’s definitely a significant issue, sure, especially lately, and one a number of others have vocalized too. When it comes to summing up the results of a discussion, accepted and rejected ideas and key points can and ideally should be documented as part of the PEP, e.g. in the Rationale, Rejected Ideas and other sections as appropriate, at least once its ready for resolution (and both we PEP editors and PEP delegates try to at least nudge authors to make sure they do this).

However, as to continually providing an updated summary of each current discussion in progress; this would generally require at least one person who is well-versed, -motivated and -resourced, along with deciding on a venue to post such roundups (such as a weekly Discourse thread).

Perhaps the packaging newsletter that @pradyunsg proposed would be a good fit for this, if carefully curated, but of course as with almost anything in the packaging space, the key constraint seems to be simply finding people with the expertise, motivation and bandwidth to do it. If you’re volunteering, I’m sure you’d be a great fit for this—but I understand if its too much of a commitment.

Theoretically, that’s something perhaps a suitably trained LLM could help summarize. However, that would raise a whole minefield of issues, and I and I’m sure many others would be quite skeptical of its accuracy, particularly on such a specialized topic. I’m not sure there’s really a substitute for at least one diligent human per thread following along and writing up a summary (like, e.g., LWN sometimes does).


In my head such a creation/curation would be done by community manager who we don’t really have at the moment.


PEP threads have the advantage that there’s someone in the author role.

Let’s assume I’m ready and willing to write a concise summary of the PEP 735 thread (I’m not sure I am at the moment, but soon). Where do I put that summary? Is it a new thread?

I don’t think it’s the only thread which has become too long to read. Maybe it’s the most recent one though, so I’m happy for it to be the first example / case study.


Thanks, though not a new thread, please. It will also get out of date as the discussion unfolds. Isn’t summarizing everything related to a proposal the very purpose of the PEP process? We could make each proposal in the initial post of a thread, but we make larger proposals editable PEP documents so that understanding the current state of the proposal can be done without following all details of the discussion.

IMHO, you should simply expand the Rejected Ideas and Open Issues sections as much as possible.


Yup! It’s fairly common to have “here’s a second iteration” with a summary of what has been discussed + changed in the PEP.

1 Like

Yup; that’s the idea, anyway :slight_smile:

Right, as a new PEP thread when the PEP is revised accordingly, and make sure to update the Discussions-To and Post-History accordingly with the link.


Huh, I’m curious what makes you say that a new thread is a bad idea!

It does require that OP do a few logistical pieces to avoid derailing discussions:

  • on the old topic…
    • make a comment that there’s a new topic, and flag your own post to moderators asking them to close the old topic.
    • have moderators close the old topic, redirecting folks to the new topic
  • in the new topic…
    • include a summary of the discussion
    • mention what changed between the last iteration and this one
  • update the PEP to have the relevant discussions header)

This avoids the discussion from having multiple parallel tracks. I do think that having a new topic serves to provide checkpoints to the evidently-large discussion.


I was mainly requesting not to post the summary of the discussion exclusively as a Discourse post but to also incorporate it into the PEP.

Also, I was under the impression that the idea was to post a summary in a separate new thread but keep discussions on the old thread. That sounded like it would quickly lead to two parallel discussions. A new thread for the main discussion is fine, preferably closing the old one.


As someone who for personal reasons cannot attend the summits, and yet has strong opinions on packaging topics, I don’t particularly like this aspect of the current situation. I’d like to see a better way for remote-only participation in the sort of topics we are talking about here. So I’d support what @willingc is asking about, and go further in terms of giving non-participants in the summit a better voice.


Ah, indeed! I agree that the PEP has to incorporate the discussion in some form (either changing the main proposal or adding rejected ideas etc).

Moving the discussion back to on-topic…


We did collect them initially at Issues · pypa/packaging-problems · GitHub, but then we added a pointer from the beginner tutorial to ask questions there and overwhelmed that issue tracker with those questions. :sweat_smile:

It might be a good idea to split those two uses apart again. GitHub allows transferring issues between repos now, and it might make sense to do that for this situation.

I agree.

Indeed – improving this would be extremely valuable, both as a contributor and as someone who has had to explain to people what is happening and such.

Thank you for both asking about this and bringing this up.

1 Like

I’ve gone ahead and edited my original post and converted it to wiki format to try to summarize the responses from the thread to this point.