On core dev bottleneck there were 10.5k PRs merged across different branches since GitHub transition with 4k PRs made by three core devs including miss-islington (2k PRs). So around 40% of PRs were created with three accounts. The number of open PRs is also keep creeping up that I guess there were 750+ open PRs by September 2018 and the count might be 1000 in few weeks with currently 990+ open. This might cause bus factor problems especially with most of the development unpaid and on volunteer time when people move on to different endeavors. There is also no major company backing up the development directly with respect to finance like Go, Java, C# etc. to hire new developers to take care of development and so on.
As a personal experience moving to GitHub with automation saves a lot of time, reduce workflow related bottlenecks and can attract new contributors. Like for a doc fix I can edit it on GitHub with a fork and make a PR where previous setup required a patch to be uploaded. But with a project like CPython that is highly stable the number of low hanging fruits to work on is also less. Some people might find that after a few months due to lack of motivation on trying out other areas due to lack of platform specific knowledge, less C experience etc. to move on to other stuff once they make an initial set of improvments. So there could be potential candidates who were highly motivated initially about the project that might be missed out on converting them to long term contributors due to lack of feedback, mentorship, direction etc. So this adds another set of tasks to the core team in addition to their own tasks at hand during volunteer time. I am sure these have been discussed a lot across different timelines but without full-time devs I hope there is a long term plan while dealing with new contributors and old contributors cycle so that people enjoy contributing with less entitlement on contributor and core dev part.
I would also recommend “The hard parts of open source” by Evan Czaplicki, creator of Elm https://youtu.be/o_4EX4dPppA
Edit : It’s a known problem even with large open source projects even with a company/foundation behind it.
Two rust core devs left Mozilla last month and there were talks about an independent foundation to drive development and finance.
Clojure receives periodic attention about software entitlement around process and core team at Cognitect who steward most of the development.
Perl6 uses grants for development and new features.
I can’t discuss your presentation in detail because I don’t know what you said over those slides, but I don’t think it helps to make caricatural statements such as:
“Tech is easy” (is it? perhaps if you have 15 years of experience and eschew the remaining hard topics… otherwise where’s the CPython JIT that solves all performance problems? )
“Python is all about people” (should we stop caring about features or regressions?)
But, yes, there are structural issues in community-driven open source projects.
The PSF is getting a lot of money from large companies: Python Software Foundation Sponsors | Python Software Foundation But right now, this money is not used for grant to sponsor the development of Python itself. Tell me if I’m wrong, but the money is more used for events and sprints.
I am happy that it’s used for sprints and events but my point being CPython with developers paid to work on CPython could be more different and sustainable. Given devs can spend more time on development, mentoring etc. as a full-time job since volunteer time is always short with family, hobbies, employer work load etc. Though I have to admit it comes at the cost of the company eventually making an influence on the language like Google on Go, Oracle on Java etc.
For English speakers, I would suggest you to wait until the Devconf.CZ video is online. If you cannot wait, you may try the automated translation of the French subtitles. I reviewed the subtitles in french, but it looks like the automated translation is good.
(I also proposed the same talk to Pycon US, we will see if it’s accepted )
I definitely agree with this, it’s really demotivating as a contributor when PRs sit around for months without any feedback. Then finally when someone gets around to it there’s suddenly merge conflicts and the code base has changed underneath. It’s also hard to gauge what issues are in the area of interest of active core devs, it is far too easy to make a patch for an issue in some corner of the stdlib that hasn’t been touch for years. Every few months or so I’ll trawl the issue tracker, make some PRs but then get demotivated by this reason really fast.
The path to being mentored by an active core dev is a little bit hazy as well, it seems like a lot of the recently mentored people have been going to conventions and sprints and actually meeting some core devs in person. It’s hard to find information online on which core devs are looking to actively mentor people, who they’re looking for etc.
One of the biggest problems I’m finding with my mentee is finding issues that aren’t just vapor locked by indecision. “Oh this looks like a nice, easy problem to work on” and then we find it’s got years and dozens of comments. That’s extremely daunting for new contributors and veterans alike. I hope that one of the topics the SC will take up is how to make progress --any progress-- on such issues.
This could lead to lot of work staying at GitHub. Looking at old PRs there was a cleanup sometime back with the addition of label indicating inactivity where there are now merge conflicts but the PRs have comments that either contributor or dev has lost track of. This snowballs itself and with 1000 open PRs yet another such activity could only result in further alienating newcomers.
Regarding the interest of the devs though everyone acts with the best of interest there is lack of time, greater interest in another area etc that they wish to prioritize upon that no one can have a say on. The modules themselves have to be maintained somehow updating to latest protocol, standards, RFC, etc especially when there are modules that were inherited from Python 2 that are going to stay in stdlib throughout python 3. It causes technical debt where no one has expertise or interest to review code in the area though it’s broken or has to be enhanced in future to attract users to migrate to python 3. This is a general problem with maintenance across all languages based on volunteers and it’s just CPython incoming contribution rate magnifies this effect.
Regarding travel I always feel travelling to sprints to meet core devs in person is great but these are little localized in my opinion given the geographial area. Many of the larger python events happen in US and unless there is sponsorship or the attendee is situated near US it could be costly. I am from India and just travelling in flight with VISA to US excluding hotel and food would cost me INR 150000 while my monthly expense is INR 15000 so I will mostly prefer latter over the former and this can get higher becoming a significant factor even with sponsorship. This is also a little hard one to solve.
Howto engage Python contributors in the long term?
My honest answer is “I don’t know” . This is a personal question in the volunteer project.
Everyone has different motivation. I only try to keep finding motivation to do good work at whatever things I am spending my time on.
More general answer.
Helpful and timely feedback helps.
Progress helps.
Bringing excitement by new features helps.
Inclusive community helps.
Great Developers are an inspiration to continue.
Ability to learn something new is a great motivator to stay engaged.
Your slides talk about misogyny, bullying and racism. Those are bold statements. Did something happen at conferences, ml, github, BPO or something? Are there practical examples regarding candidates or contributors who have been marginalized due to their gender, ethnicity, etc.?
The PSF can (and should) spend money on Python development. Unfortunately, we do not receive grant requests for such funding. We are not yet in a place where we (the PSF) can actively search for these types of requests ourselves, but once the SC is in place I would love to start a discussion on this.
My talk tries to be more general than just the Python community, but yeah these things happen in Python as well. Multiple core developers were against my master/slave change. Sorry, I cannot elaborate here because victims don’t want to talk and events usually happen in private. I tried to only mention events which only involve myself to not put the spotlight on victims who didn’t ask anything.
Maybe ask people who handle Python CoC reports if … they get reports?
Ah, by the way, I have been harassed for 2 years in Python as well, but I don’t want to talk about that. Not in Python at least.
Once I became aware of the issues, I have been amazed by the number of victims and the violence of reactions. I am not talking about the specific case of Python here, I am talking about “the Internet” in general.
Some women started to speak out, write articles and books. They are usually targets of trolls and haters. Some get murder threat or worse.
Maybe ask some women around you if they feel respected and safe online, and if they get offended or harassed online. Or if they know any friends in this case. If you get no complain, it may be because they don’t feel comfortable to talk about these sensitive topics with you. It doesn’t mean that everything is fine.
I am a bit familiar with this topic and I can say this is a field I would treat with caution. And the reason for that is because you’re entering a political territory which has been subject to abuse by a minority of external (often anonymous) contributors (including python). I skimmed through some of the links you mentioned. This is one I was familiar with:
The author of that ticket is well known. She is the author of the Contributor Covenant CoC which has been (ab)used in order to try to kick developers out of open source projects on account of what they write on their Twitter profile as the CoC explicitly allows for that:
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
The same thing happened to Linux, which also adopted a variant of the Contributor Covenant CoC (here’s the diff and a long, heated discussion), and I’m pointing this out because in another thread you mentioned the Linux Code of Conflict as an example of aggressive behaviors.
So I would not take those 2 cases as an example of “positive diversity”. I could provide links about other open source projects which have been subject to similar attacks (almost always portrayed via CoCs and a distorted concept of “diversity”), but I don’t want to go too OT here. Both cases (Opalgate and Linux CoC) are summarized here.
I am at Brno (Czech Republic) for Devconf.CZ where I just gave a talk:
I’m not far from there. Wasn’t aware of the conference. Depending on your schedule we could meet in person.
Yes, inclusion is a topic that should be treated with respect and thoughtfulness.
There are many aspects to what helps make a community inclusive, healthy, and productive. It’s my hope that this is kept in mind as our community grows. It would be unfortunate to only approach from sensationalist media coverage where often only one point of view is presented.