Vote to promote Joannah Nanjekye as a core dev

Committers
1

Hi,

I’m mentoring Joannah Nanjekye for more or less one year. I followed closely her progress on learning the Python workflow and Python internals. From my point of view, she is now ready to be promoted as a core developer.

I open the vote for one week. A promotion requires at least two-thirds positive votes and no veto by the Steering Committee (see PEP 13 for details on the process).

  • Promote Joannah Nanjekye
  • Do not promote Joannah Nanjekye

0 voters

(Vote config: single choice, results: always, don’t show who voted, close automatically at 2019-09-23T13:30:00Z)

EDIT: I had to delete the old poll (by adding “name=poll2” to the poll) to change “results: staff only” to “results: always” (the config was wrong). I couldn’t edit the old poll config 5 min after its creation. To the 4 persons who already voted: please vote again.

I prefer when votes (positive or negative) are commented. IMHO it helps others who are not sure to build up their opinion, and it can help the candidate to work of their weaknesses (nobody is perfect, especially me). You are not required to justify your vote. If you don’t want to comment your vote in public, you can contact me in private.

If Joannah is promoted, I propose to mentor her for one month to handle her new responsibilities.

Biography

Joannah Nanjekye is compiler researcher in the Python IBM lab at UNB (Canada) and an aeronautical engineer.

She started the PyLadies Kampala community which has now around 200 members!

She also authored the “Python 2 and 3 Compatibility: With Six and Python-Future
Libraries” book in 2017.

CPython Articles

She wrote articles about the CPython development:

CPython

Joannah likes to work on low-level features like the os and socket module. She is not afraid of writing C code. For these reasons, it took her more time to become ready, since modifying low-level code requires to learn more things: reference counting, Python C API, check portability (Windows, macOS, Linux, FreeBSD); in addition to more regular expected skills: handle backward compatibility, document properly changes, etc.

I gave her the bug triage permission last February: python-committers: Joannah Nanjekye got the bug triage permission.

She is active on https://discuss.python.org/ For example, in the Core Workflow
section.

She attended the CPython core dev sprint at London last week. Where she worked on the High level implementation of the subinterpreters module (i.e PEP 554): https://github.com/nanjekyejoannah/cpython/pull/1

Significant Joannah’s work in CPython

Most recent to least recent significant merged changes:

  • bpo-28724: Add methods send_fds and recv_fds to the socket module (GH-12889)
  • bpo-35943: Prevent PyImport_GetModule() from returning a
    partially-initialized module (GH-15057)
  • bpo-15088: Remove PyGen_NeedsFinalizing() (GH-15702)
  • bpo-37878: Remove PyThreadState_DeleteCurrent() function (GH-15315)
  • bpo-36833: Add tests for Datetime C API Macros (GH-14842)
  • bpo-15542: Documentation incorrectly suggests init called after
    direct new call (GH-15478)
  • bpo-15913: Implement PyBuffer_SizeFromFormat() (GH-13873)
  • bpo-37531: Fix regrtest timeout for subprocesses (GH-15072)
  • bpo-36487: Make C-API docs clear about what the main interpreter
    is. (gh-12666)
  • bpo-22640: Add silent mode to py_compile.compile() (GH-12976)
  • bpo-36475: Finalize PyEval_AcquireLock() and PyEval_AcquireThread()
    properly (GH-12667)
  • bpo-35537: Add setsid parameter to os.posix_spawn() and
    os.posix_spawnp() (GH-11608)
  • bpo-35674: Add os.posix_spawnp() (GH-11554)
  • bpo-35537: subprocess uses os.posix_spawn in some cases (GH-11452)

Using posix_spawn() can make subprocess up to 60x faster! It’s a really cool
optimization which is already part of the incoming Python 3.8.0 final release.
Currently, posix_spawn() is only used on Linux and macOS under some conditions:
https://docs.python.org/dev/whatsnew/3.8.html#optimizations

She added socket.send_fds() and socket.recv_fds() which will be part of Python
3.9. It was not easy to write code working on FreeBSD, Linux and macOS:
SCM_RIGHTS is a little bit platform dependant. It’s really nice to have such
simple helper functions to exchange file descriptors on UNIX/BSD platforms.

I was impressed that Joannah dares to modify PyEval_AcquireLock() and PyEval_AcquireThread() in ceval.c (bpo-36475). These are part of the most low-level GIL functions. She changed how threads handle Python finalization which is a very fragile part of Python, but now a little bit more reliable (thanks to this change).

All Joannah’s commits: https://github.com/python/cpython/commits?author=nanjekyejoannah

Future Plans

Joannah’s Planned future work on CPython:

  • Implement PEP 554 for use in test suite. Until PEP 554 is accepted (or if it isn’t) we should add a PEP 554 implementation as Lib/test/support/_interpreters.py (e.g. test.support._interpreters ).
  • Work on fixing subinterpreters’ related issues.
  • Take a closer look at Garbage collection.

Victor

3 Likes
2

I voted Promote because Joannah clearly seems ready, having taken on useful low level internals work in some of the areas I’m familiar with. All while getting code or design reviews from the right folks.

1 Like
3

Oh no. I made a mistake, I created the poll with “results: staff only”, whereas I wanted “results: always”. I had to delete the old poll to create a new one which removed old votes.

To the 4 persons who already voted: please vote again (on the new poll).

1 Like
4

A bit of back-and-forth seemed necessary on the PRs I looked at, but given those tackle non-trivial topics I still voted +1. Joannah is generally receptive and non-bullish, which is a plus here.

3 Likes
5

I agree with that. I trust Joannah to not merge her own PRs before another core dev approved it. That’s not different from any other core dev.

When I reviewed her PRs, I was very picky to learn them all minor things that I care about :slight_smile: And as you and me wrote, she worked on complex changes. Changing how Python finalizes threads is more complex than fixing a typo in the doc, just to give one example.

6

Since I was one of the ones asking for people to explain -1 votes in this thread, I thought it is only fair for me to chime in here with what reservations I have about this.

On the one hand, I am a bit of a “commit bit maximalist” since I don’t think there is much if any downside to giving people commit bits prematurely. There was apparently a stretch of time in the past where attending a sprint was enough to get a commit bit, and as far as I can tell there were no real ill-effects from this.

On the other hand, if I were judging “readiness”, I am not sure I would have enough information to go on here. It seems to me that a big part of being a core dev is reviewing PRs and making decisions in issues - one could make the argument that you mostly only need the commit bit in order to do reviews, since hopefully even core devs are getting reviews before merging. It seems that she has done very little in the way of reviews, see this query, which turns up 6 closed and 2 open PRs. Most of these are procedural comments and two useful reviews of the wording in documentation 1, 2.

From speaking to Joannah and discussing issues with her, I will say that she is smart, capable and responds very well to feedback (and by this I do not mean that she capitulates - she formulates well-reasoned responses that sometimes agree and sometimes disagree with you). I would have no problem voting +1 based on her potential - I think that even if this vote fails, it will definitely happen eventually and I don’t see a particularly significant risk here. If I were voting based on whether I think she needs a commit bit right now, I would probably vote -1, unfortunately.

For now I will abstain from voting, and I hope that my comments here are taken as the constructive feedback I intend them to be, and not as a criticism of anything innate in Joannah.

5 Likes
7

I voted in favor. Joannah will make a great core developer for a variety of reasons. More than anything, I trust her with the stewardship, both of safeguarding the code and of thinking of the Python community. Joannah is committed to the project and takes the responsibility very seriously.

Other valuable qualities:

  • easy to work with
  • really smart
  • diverse background (e.g. pilot)
  • already has strong technical skills
  • willing to challenge herself
  • already active in encouraging others to contribute to Python

Anecdote: This last week at the core sprints in London I filled in for Victor as Joannah’s mentor. I did an okay job, but she did a great job. Not only did she work on subinterpreters with me (her idea, I swear!) and other various issues/PRs, but at one point she sought out Pablo to get a detailed explanation of how GC works. That really impressed me. That sort of initiative demonstrates a valuable At the end of the sprint she presented a lightning talk with me on our progress with subinterpreters. (She did great.)

Finally, Joannah has expressed an interest in working on the core runtime. That’s an intimidating part of the code base to which not many new contributors are either willing or ready to contribute. So I get excited when someone is interested in it and shows they can be helpful there. I am convinced that Joannah fits that description. :slight_smile:

3 Likes
8

To other aspiring core contributors:

My description of Joannah is sincere, but not some checklist nor criteria. Please do not feel like you have to be some kind of technical wizard or community superstar in order to become a Python committer. Believe me, we don’t compete nor gate-keep like that. Rather, we want people who care about the language and its community. We ask ourselves, do we trust this person with the responsibility? Everything else is typical nice-to-have.

So please don’t think you don’t measure up so you won’t try. Just care enough that you try anyway! :slight_smile:

8 Likes
9

I’m going to abstain, for similar reasons to @pganssle. I don’t have any reason to vote against Joannah, and I would love to see more people with the ability and interest in working on lower level features. In particular, I’m happy to see that she’s interested in working on subinterpreters. But I’ve not had any direct interactions with her, possibly only because, with the variety of different places interactions take pace these days, we’ve not been involved in the same threads. And so I don’t really have any personal experience to base a view on.

I don’t tend to factor “does the candidate need commit rights” that highly - if someone is interested and qualified, I’m inclined to say promote them - core dev status is something people are proud to be given, and why shouldn’t we be generous in giving that acknowledgement to people who deserve it?

In the past, I’d have happily voted +1, basing that on what others are saying and my own views on where it would be good to have additional core dev resources. But a +1 vote these days seems to require something a bit more than that, so I’ll choose to leave the decision to others with more direct experience.

So ultimately my reasons for not voting are more about the new process than about any reservations I have - I hope Joannah gets approved, and even if she doesn’t this time, it seems like it’ll only be a matter of time.

3 Likes
10

Which is why I just voted to promote: to oppose the trend toward raising the bar into the stratosphere :wink:. I haven’t interacted with this candidate at all, but based on what others have said and my own views of who would helpful, plus that Victor intends to continue mentoring for a while, I have no significant reservations.

If it turns out to be a mistake - which I highly doubt - fine: “core dev” isn’t a lifetime appointment. It can be revoked, and we can blame Victor for the hassle :wink:.

That doesn’t mean I’d promote anyone who asked. This candidate has clearly established a significant track record of accomplishments, and I haven’t seen anyone yet say anything affirmatively negative about their experiences with them.

7 Likes
11

FWIW, I’ve noticed the same thing. I’ve opened a separate thread related to that topic.

2 Likes
12

Personally, I definitely don’t think this is the right way to think about it.

First, we’re overwhelmed with unreviewed PRs. We’re understaffed. We need her more than she needs us :slight_smile: So it doesn’t make sense to vote for someone based on how much they need the commit bit.

And second, in CPython’s culture right now, the commit bit is much more than just the commit bit. It’s a mark of acceptance, it’s an invitation to participate in committers-only discussions, it’s a ticket to attend the annual sprint and language summit, it’s required to bring PEPs forward for discussion, it’s the right to participate in governance decisions… and conversely, rejecting someone as a core dev sends the message that they aren’t welcome in those discussions, whether or not that’s what we intend. So it doesn’t make sense to base this decision on commits alone.

Since I became a core dev I haven’t made many commits, so if the criteria is based on committing then I probably don’t qualify. But I’d still like to think that I’ve contributed in worthy-enough ways. For example, if I wasn’t a core dev I wouldn’t be allowed to participate in this conversation.

8 Likes
13

I strongly support promoting Joannah as a core dev. She was an asset to the recent core development sprint. She shared her knowledge to a wider audience with the co-presented subinterpreter talk with Eric.

She’s been committed to CPython development - triaging, bug fixing, and low-level code modification and review.

Thank you Victor for mentoring, and I hope to see Joannah being promoted soon.

7 Likes
14

2 posts were merged into an existing topic: Concerns about how we vote on new core developers

15

I’ve just changed my mind and voted in favour. I think (no change to my position on this) that Joannah would be a definite asset to the team, and have no reservations in voting for her. What’s changed is that the comments about how we’re risking becoming too cautious in who we accept persuaded me to go with my instincts and not with some vague sense of what is “required” for my opinion to be valid :slight_smile:

9 Likes
16

The vote ended automatically 23 minutes go with 30 votes:

  • Promote: 24 votes (80%)
  • Don’t promote: 6 votes (20%)

I’m now waiting for the Steering Council pronouncement.

1 Like
17

On behalf of the Steering Council, we support Joannah. Congrats go to Joannah, and thank Victor for helping her this far. IIUC Brett has to do the honors of actually setting her commit bit in various places.

12 Likes
18

I don’t know if I have to, but I have the appropriate permissions everywhere, enjoy doing it, and I have the process memorized at this point so it’s probably the most convenient to have me do it :wink: (although I do plan to document it in the devguide after I get Joannah set up).

5 Likes
19

Thank you all and to Victor for the pre and post mentor-ship.

I was glad to have come for the Language summit at Pycon and the core developer sprints recently (Thanks Eric for mentoring) and I can say Python is in good hands. Its a great honor to join the team that has facilitated the Python users and community with quality Python releases over the years. But most importantly am glad to be part of a warm community.

I am not perfect to help in every area of Cpython but I love to learn. To other core devs, teach me something If you get an opportunity. I have saved to memory some feedback already so thanks for that.

I believe this is accessible by the public. So, for any potential new contributors to Python, Python is like a big piece of land that we can all have a piece to garden. Come let us reason together!!

For God, my country and now Cpython! :slight_smile:

13 Likes