Meta: Change governance model of pybind11 project?

[wjakob]

Dear all,

here is a meta-topic that I'd like to discuss with the rest of the pybind11 community.

It's only been about ~1.5 years since the first code drop of this project landed on github, and many things have happened since then. The first is that this project has developed quite a significant following! We have a > 2K clones/day on good days, close to 2K "stars" (whatever that means ;)) and a significant amount of activity on the tracker and chat. It is clear that this project is doing quite well as far such metrics are concerned.

The more important thing that these metrics don't capture is that we've also assembled a community of contributors who deeply care about this project, and who have fundamentally shaped the evolution of this project with improvements of absolutely outstanding quality. I'm constantly amazed how this has allowed pybind11 to scale to an ever-increasing number of needs while keeping its internal design simple and clean. Well done! :)

Thus far, I've acted as the BDFL and had the final say on a number of decisions. But being a busy tenure track prof, my availabilities for code reviews and and other open source-related activities are often unpredictable and far apart, hence this process has not always been smooth. It often seems to me as though I'm the bottleneck on things that should just get decided/merged right away. As the project grows further, this could eventually become problematic. But this way of organizing things also strikes me as silly: why should I be the one to make these decisions? Others are (demonstrably!) at least as qualified and invested into this project, hence I don't see why there needs to be a BDFL at all.

That motivates this meta-issue. I'm wondering if we should extend the leadership of this project or adopt a different kind of governance model. That makes it sound very bureaucratic, which is of course not the intent: I just think that the project is big enough so that the sole responsibility should not rest on one person. An extreme change would be to adopt a formalized process like C4 (explanation). A lighter weight option would be to promote a number of community members to moderators and try to reach a certain quorum based on how intrusive/useful a new feature is deemed to be before merging it (but then any moderator could do that). These are just a few possibilities to start a discussion -- of course I'm mainly interested in your ideas.

Best,
Wenzel

[jagerman]

A lighter weight option would be to promote a number of community members to moderators and try to reach a certain quorum based on how intrusive/useful a new feature is deemed to be before merging it (but then any moderator could do that).

I would definitely prefer a more informal approach, at least at the current level of development, to a more formalized process. I don't think small fixes and PRs (e.g. the doc fix in #672, or the doc change in baec23c) need a quorum (or even a PR, for the latter), while larger ones (e.g. #610, #679) benefit from sitting around for a while to attract comments/feedback.

I think as long as there is a general understanding that major features need more review and agreement, and that really shouldn't be merged without having a thorough review by someone else, or while there are outstanding concerns (not just by moderators). Common sense stuff, really.

My opinion is that I don't have any objection to a formalization of the process, but I also don't think that it's needed with a fairly small number of moderators as long as the process continues working without issues/conflict.

[dean0x7d]

I think as long as there is a general understanding that major features need more review and agreement, and that really shouldn't be merged without having a thorough review by someone else, or while there are outstanding concerns (not just by moderators). Common sense stuff, really.

👍

I agree with @jagerman about the lighter weight option. I don't have anything against a more formal process either, but the size of the project probably doesn't warrant going too formal right away.

I think starting a bit lighter would be nice, with the immediate goals to better keep up with the pace of issues/PRs and to ease the burden on @wjakob. That's not to scoff at @wjakob -- the response times have been stellar overall and the rapid issue-solving has been pretty impressive to see. But at the end of the day, this doesn't put food on the table so it can't be a priority when the volume increases.

[wjakob]

I would definitely prefer a more informal approach, at least at the current level of development, to a more formalized process. I don't think small fixes and PRs (e.g. the doc fix in #672, or the doc change in baec23c) need a quorum (or even a PR, for the latter), while larger ones (e.g. #610, #679) benefit from sitting around for a while to attract comments/feedback.

Wonderful. It sounds like we all have the same thing in mind. I've invited both of you to be members of the project.