Governance - or, "what do we do with all these pull requests?"

[danieleades]

It's a testament to the quality of this project that it attracts such a high volume of issues and pull requests. Poetry is a pleasure to use and solves a fairly universal problem in Python development. For that reason, it's fast becoming a ubiquitous choice for package management.

By virtue of being so popular, and also because it's so exposed to the host system (by it's nature), Poetry users find no end of possible improvements, bugs, or unsupported edge cases. At the time of writing there are 1.1k open issues and 214 open pull requests. Because (presumably) of the high volume, many of the issues are ignored, and many of the pull requests stay unreviewed until they stagnate. at the time of writing there are 364 open issues or pull requests that have never received a single comment (is:open comments:<1)

Admittedly there's probably a lot of garbage in there, but it's not the most welcoming environment for would-be first time contributors.

I don't have a solution here, but i think it's pretty clear some structural/governance changes are required to sort through and make sense of all of this in a constructive way.

[danieleades]

I don't know how to solve this, but I suspect "more maintainers" is probably the actual best way forward.

I've not spent any time on the Discord server, but it looks pretty active, and i'm guessing that's pretty useful. Has that been the general experience?

some possible ideas-

More Maintainers

throwing warm bodies at the problem is a tried and true method, but managing to do that while maintaining code quality and project vision will require changes to the eponymous Governance. Involving more people in a project involves a democratisation of trust, vision, and quality. Doing that could require more stringent code quality standards (see below), and will almost certainly involve a much clearer statement of...

Project Vision

Goals, Non-Goals. Detailed roadmaps (#1856 is a pretty good start). Types of pull requests that will be considered, and types of pull requests that will be summarily closed. PRs in the first category should be reviewed quickly. PRs in the second category should be closed quickly. Probably stale PRs should also be closed automagically. You'll notice there's no "eternal purgatory" category, that's intentional.

Code Quality

Code quality in this project is pretty good. Continuing to ratchet up those standards provides greater confidence when merging and reviewing pull requests.

a couple of potential improvements here:

• track and report code coverage as an informational tool when reviewing pull requests. codecov is nice for this.
• incrementally introduce typing to the codebase

just spitballing here. Not trying to start a flame war on python's optional typing.

monetisation/incentives

i'm naturally wary of these things, but adding bounties to bugs could potentially provide a way to sort them, and to provide an incentive to actually address them. This doesn't exactly help with the unreviewed pull requests problem, at least not directly. issuehunt looks pretty slick.

It might also be possible to attract some micro-sponsorship to support the maintenance, but I have precisely zero experience with these platforms and have no idea whether they're effective.

[colindean]

Relevant, hopefully more so as others post: What are the best texts to learn about issue triaging approaches?

[danieleades]

current state of affairs:

1.1k open issues
146 open pull requests
34 issues/PRs have never received comments

that's down from 1.1k, 214, and 364 respectively when i opened this issue. @neersighted take a bow

still a way to go.

[danieleades]

maybe we can automatically reap the stale issues and PRs?

see #4896

[neersighted]

I'm going to close this for now -- it has been exactly one year since this was opened. Since then, we have tripled the number of maintainers with a commit bit, and developed several new subject matter experts. We have recently introduced a large infusion to our triage team, and they are diligently working on the issues in our repositories.

I still think that project governance needs some thinking about going forward, but we are increasingly in a good spot to do that, and I think we would be better off taking the temperature and discussing ideas offline, then posting a actual proposal for governance for wider review, versus trying to tack on to this.

Our current model, for the record, is @sdispater serving as a psuedo-BDFL (more by other contributor's respect than due to a choice on his part), and operation on ad-hoc/rough consensus with the 'revert' button always being an option if needed. @sdispater, @abn and I are currently serving as custodians with more access to/control over Poetry's infrastructure (e.g. GitHub org, Discord, Vercel, etc).

This is working well for now, but if we can come up with something better that will make Poetry development easier and faster for contributors, we should consider it.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.