https://www.b-list.org/weblog/2018/nov/20/core/
Given we’re being inspired by their governance model in some of our proposals, we probably need to chat about the problems they are seeing in their model. Some certainly also apply to us.
The problem as stated:
for some time now, the project has not managed to bring in new committers at a sufficient rate to replace those who’ve become less active or even entirely inactive, and that’s not sustainable for much longer.
The proposed solution:
So what I’ve proposed is the dissolution of “Django core”, and the revocation of almost all commit bits. They’re mostly unused anyway!
In place of the committers, two roles would be formalized — Mergers and Releasers — who would, respectively, merge pull requests into Django, and package/publish releases. But rather than being all-powerful decision-makers, these would be bureaucratic roles; no single person would have the authority to write up code and push it into Django on their own. The initial set of Mergers would be the current set of Fellows, and something similar will happen for Releasers.
In place of the (in theory) committers making decisions, governance would take place entirely in public, on the django-developers mailing list, with anyone who wants to participate in good faith free to do so, including voting in favor of or against any controversial change. This already basically is the way things work.
So, given the author is proposing to remove the notion of “core developer”, it’s actually quite a radical change that’s not on the level of any of our governance PEPs. If we think their proposal is serious and worth considering for CPython, then all governance PEPs have to be rewritten 
(I also think that the whole idea that removing commit bits will increase participation is nonsensical. It’s like pushing buttons at random when you have a problem, in the hope of solving the problem by chance. But, well, I don’t know the Django community, so perhaps there are serious reasons that the document doesn’t state?)
1 Like
I don’t think the proposal is dropping the commit bit from a git perspective so anyone can merge. It seems there will still be all the current Django core devs who will have commit/merge privileges, but that’s the only privilege they hold compared to external contributors. So I’m assuming this would mean all PRs even from current Django core devs will need to go through at least one review just like an external contributor. This is obviously on top of no longer holding special voting rights for making decisions.
Apparently:
The initial set of Mergers would be the current set of Fellows, and something similar will happen for Releasers.
Fellows seems to be something much more specific than committers. They are paid by the DSF to handle various maintenance tasks. For example, according to this post, in november 2017 there was a single Django Fellow.
So the proposal does seem to remove the commit bit from most people.
Yep, it’s really trying to make hitting merge the boring part, which on its own seems like a reasonable idea. Separating code contributions from other involvement generally feels good, and it lets them define the “famous” roles differently. (I’m fairly uncomfortable with the “fame” of being a core developer, and see it far more as a responsibility than a privilege or reward, so that aspect sounds pretty good to me. Of course, I’d still be a Releaser in this proposal, so it’s less impactful for me than others.)
I don’t think we’re going to make any changes this dramatic, though as most of our new models involve electing the “higher powers”, it wouldn’t be a huge jump to have a class of electors who don’t ever touch the code base directly. (Again, not proposing it right now, but it’s an interesting thought experiment.)
Yep, you’re right. My bad for reading this while waiting for the subway. 
I would be curious to know how much the Fellows handle in terms of merge throughput compared to other Django core developers? James says “most actual commits to the main Django repository are made by the Fellows” so it would seem like a good amount but I wonder what the actual percentage is?
But they also have a different scale issue, i.e. Django had 36 PRs over the past week while we had 77 PRs without counting miss-islington (which if Django gets by with 2 Fellows would suggest we could manage with 3 - 4 equivalent full-time staff).
I don’t know, but looking at the recent commits it seems most were merged by Tim Graham. And by most I mean something like 95%.
1 Like
While I don’t think the specific changes Django are proposing are relevant to us, it does make me wonder whether the PEPs we have which take inspiration from the Django model need to address the question of “how do we avoid the problems Django is encountering?” Although the answer might simply be “we’re different, and their issues don’t affect the relevance of their governance experience to us”…
1 Like
I don’t think it does. Think of what James is proposing for Django more like what the other PEPs specifying what a core dev is and how to choose them. It really isn’t about governance since the committee is sticking around for Django.
tl;dr - the problem is real but can’t be solved with committer democracy. This is off topic for governance PEPs. Ranty monologue on the future of Python, beware.
When I read James’ proposal, my first thought was that he is seeing a real problem (low contribution levels) but is focusing on the wrong problem to solve it (committers vs. the world).
There are JavaScript projects now with high tens if not hundreds of committers and it’s all good. Our problem is likely that mature systems like Django and Python in general hit their generational aspiration. They are no longer attracting so many new contributors because the new generation started on a different ecosystem (like JavaScript, Android, iOS, etc.) and doesn’t use Python at all.
So this problem is very real for Python core, too. It is in large part out of scope for governance PEPs. We need to attract newcomers by mentorship, inclusion, timely responses to issues and PRs, and so on. What would help the most is making the language attractive to the new crowds:
- make and maintain an official WebAssembly target;
- make Python officially supported in Unity (games, mobile, VR);
- make Python more performant and multicore-friendly to keep the numeric crowd around (TensorFlow is investing in Swift);
- make Python more statically introspectable to enable awesome IDEs and keep the big users around.
In other words, it is no longer 2007 and despite Python’s awesome adoption, we painted ourselves into a corner quite a bit. The relatively low contribution levels from new people are an indicator of this. Of course, Roundup doesn’t help, mailing lists don’t help, relative lack of low-hanging fruit doesn’t help. But that’s even further off topic!
All of the above ideas for future Python improvements are obvious to most of us but they require rather massive investment. They are not weekend projects. The only way in which this is on topic with regards to the governance discussions, is that whatever government we establish, it should draw a clear roadmap for Python so that new contributors can pull in the same direction as us and have something meaty to work on.
4 Likes
Thanks for posting this @steve.dower, it’s really interesting.
My take is: it sounds like the Django team has been so successful with community-based governance that their distinction between “core team member” and “random community member” has essentially disappeared in practice. And if being a “core team member” doesn’t actually come with increased responsibilities, then that makes it a pure badge-of-being-better-than-other-people, which they think is unhelpful and exclusionary. So they’re considering how to update their formal governance to match the reality, essentially by relaxing the criterion for being a “core dev” to be “anyone who subscribes to this mailing list”.
(James’s blog post also talks about this in terms of wanting to draw in more and more diverse contributors, but it sounds to me like that’s a more general/aspirational goal, not the immediate motivation for considering this particular proposal at this particular time.)
In terms of our governance proposals, the proposal is most similar to PEP 8014, which would let everyone vote on PEPs, regardless of whether they’re a core dev.
Some important background that I think contributed to Django reaching this point:
- At least according to the blog post, their former BDFLs were always pretty hands-off, and since mid-2014, they’ve had a pure community-based governance. So these days they have lots of practice and comfort with making decisions collectively as a community, rather than relying on a BDFL.
- They have >4 years of experience now with their “Django Fellows” program, which pays a few senior folks to handle issue triaging, merging, keeping the CI running, etc. This has been really successful, and took over a lot of the routine work that core devs used to do.
- I get the impression that there’s more overlap and communication between the DSF and Django core team, than there is between the PSF and the Python core team, so the Django folks are more comfortable with the idea of the DSF acting as an emergency backstop if this latest experiment goes weird.
I think Django’s problem here sounds like a fabulous problem to have :-). But Python is in a different place: we’re still figuring out how to do collective decision-making, and our core devs are still load-bearing. In fact, we’re in a fairly similar position to Django was back in mid-2014 when their BDFLs stepped down, and they adopted their current model :-).
Regarding PEP 8016 specifically, its Django-inspired model probably isn’t the Ultimate Utopian Governance System. But I think if it’s adopted then it will give us a solid framework for tipping our toes into the water of community-based governance, and for evolving our approach as we get more confidence and experience, which is basically how it worked for Django.
I’m also really impressed by how Django is handling this discussion. I can’t see the part on their private committers list, but from what I can see it doesn’t seem to be a crisis. People are bringing up concerns and uncertainties on the PR review, but it’s all calm and productive. Everyone knows exactly what the process will be for adopting it or not. I’m looking forward to seeing how it works out.
I would not focus on the web story too much. It started with migrating the python.org site to a more modern version (we need to be attractive!), then the move to GitHub (we need to be attractive for contributors!), then the move to Discourse.
But hardly anyone comes while existing contributors have gone inactive. Could it be that people actually liked the old website and bugs.python.org and mailing lists and Rietveld?
To me it feels like doubling down on the web multiple times.
1 Like
To get back on the topic of this thread: There are many proposals how to remove, deactivate, or take away core committer voting rights.
How would this attract new core contributors? Say, someone writes a magical JIT that speeds up CPython 4x (yes, I know …). The JIT is committed to CPython, the newly minted core dev burns out and thus loses all privileges after 2 years.
I don’t see how this is attractive to anyone.
It could be interpreted as saying “your hard work matters and you don’t need to worry about someone who has stopped contributing coming in and having an equal say even though you’re putting the work in now and they had their say when they were the ones doing the work.” IOW it’s weighting decisions towards those that will potentially be the most directly impacted.
Now I have no clue if people actually hold that view or if it will make a difference in either direction, but it is a possible view.
1 Like
" But hardly anyone comes while existing contributors have gone inactive. Could it be that people actually liked the old website and bugs.python.org and mailing lists and Rietveld?"
I think it’s just part of the project lifecycle: there’s not much fun in developing CPython any more. New stdlib modules can be just released on PyPI at your own schedule instead. Most bugs are now difficult to fix and require careful researching of what the right fix is and the possible impacts. That makes it a lot like the levels of care required at a paid job, and if I’m going to do not-very-interesting and painstaking work, I may as well get paid for it.
So picking new bug trackers or web sites doesn’t help but also doesn’t hurt either. It’s just that the project has changed to be less fun and less hospitable for casual contributions.
9 Likes
From talking to a couple of folks closer to the core Django community than I am, it sounds like this is what had started to happen - the “Django core” commit bit had become less about “You get to help take care of the puppy now, aren’t you lucky?!?” and more of an ill-defined status marker with no clear criteria for awarding it.
That sounds a bit like the situation we reached with PSF membership (where folks weren’t quite clear on what the purpose of being a member actually was, beyond officially being part of the “in” crowd), which turned into the by-laws change to switch to an open membership model, and instead create the more structured PSF Fellows program to recognise notable contributions.
By contrast, for CPython core development, we have a reasonably clear idea of what the extra responsibilities of a core developer actually are (as per https://devguide.python.org/coredev/#what-it-means), it’s just that taking on those extra responsibilities comes with only nebulous benefits, and we don’t have an especially well-defined process for deciding if someone is ready to take on those responsibilities.
2 Likes