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

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?