Hi folks - Just to circle back, we have officially contracted with Łukasz Langa to be the first CPython Developer-in-Residence!
PSF announcement: https://pyfound.blogspot.com/2021/07/ukasz-langa-is-inaugural-cpython.html We look forward to seeing all the impact that Łukasz and this role will have! Best wishes, Ewa On Thu, May 13, 2021 at 3:41 PM Ewa Jodlowska <e...@python.org> wrote: > Hi folks - > > Just a reminder that we are still accepting resumes for the > Developer-in-Residence role. > > The deadline to submit a resume is May 16th. > > If you would like to chat tomorrow, Saturday or Sunday, let me know. I am > happy to share how the employee will work with the PSF and expectations. > > > Ewa Jodlowska > Executive Director > Python Software Foundation > e...@python.org > > > On Mon, Apr 5, 2021 at 4:00 PM Brett Cannon <br...@python.org> wrote: > >> >> >> On Mon, Apr 5, 2021 at 12:57 PM Ewa Jodlowska <e...@python.org> wrote: >> >>> >>> >>> >>> On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner <vstin...@python.org> >>> wrote: >>> >>>> Hi Ewa, >>>> >>>> This is really awesome! It's great that the PSF can now hire someone >>>> for that! >>>> >>>> The job offer is great, but I would like some clarification :-) (While >>>> I was part of the previous Steering Council who helped to write the >>>> job offer, sadly I was not avaialble last months when it was >>>> discussed.) >>>> >>>> >>>> Who is going to "manage" the candidate? >>>> >>> >>> Great question! The technical direction will come from the SC and the >>> people management will be Ee and myself. >>> >>>> >>>> >>>> On Mon, Apr 5, 2021 at 7:30 PM Ewa Jodlowska <e...@python.org> wrote: >>>> > The Developer-in-Residence will work full-time for one year to assist >>>> CPython maintainers and the Steering Council. Areas of responsibility will >>>> include analytical research to understand the project's volunteer hours and >>>> funding, investigation of project priorities and their tasks going forward, >>>> and begin working on those priorities. We are looking to hire an existing >>>> core developer because of the type of work involved and interaction with >>>> volunteer core developers and contributors. Need and available funding will >>>> determine any extension beyond the first year. >>>> > >>>> > Create metrics (...) Combine usage and surveyed metrics to determine >>>> which standard library modules need help and what the maintainer cost is >>>> for standard library modules >>>> >>>> What are the expected steps after the production of such report of the >>>> stdlib usage and maintenance? Hire more people to maintain most used >>>> stdlib modules, or deprecate least used modules? >>>> >>> >>>> For example, asyncio and ctypes are popular but barely maintained. For >>>> the CI, the most unstable test is test_asyncio (I asked for help >>>> multiple times on python-dev). Do we need a more detailed reports on >>>> the 302 (len(sys.stdlib_module_names)) stdlib modules? >>>> >>> >>> One of the intentions is to document these cases to better prioritize >>> funding we have and provide direction to potential future funders. >>> >>> I am sure someone from the Steering Council will want to chime in on >>> additional, more technical intentions :) >>> >> >> I think the results of the research is going to help inform what the next >> steps are (hence the need for the research 😉). Guessing what needs work >> and making a call without having at least *some* form of data seems >> premature. I also have stdlib data already for a language summit discussion >> (if it gets selected), and at worst I will just open source the Jupyter >> notebook with the charts of what I found so this won't be starting from >> scratch. >> >> Plus I suspect there will be some discussion here of what people want to >> see be worked on. While the SC is the final decider on the priorities >> simply because it would probably be a bit chaotic if the whole team tried >> to direct a single person's work, that doesn't mean things won't be >> discussed here to provide guidance and feedback to the SC. >> >> >>> >>> >>>> >>>> I understand that the first step is to put priorities in bug triage >>>> and PR reviews for the candidate. >>>> >>>> >>>> > Address Pull Request and Issue backlogs based on the developed >>>> metrics and other metrics created by the Steering Council >>>> >>>> What about the candidate skills? I don't expect the candidate to be >>>> able to fix any bug in any part of the Python. What if is the priority >>>> is a module that the candidate doesn't know? They should do their >>>> best, help debugging issues and propose a fix? I expect the existing >>>> module maintainers to remain the local autority to review pull >>>> requests written by the candidate, to avoid mistakes. >>>> >>> >> What would *you* do in this situation? The expectation is the person >> would act like any of us would: if they can fix something then fix it, >> otherwise find the person who can and help them out. There is a reason we >> hope a core dev is up for taking this job. 😁 >> >> >>> >>>> In my experience, it usually helps a lot to do a first basic review, >>>> but then ask for the maintainers of a module to do the final review >>>> and merge the change. Finding the right people for a review on a >>>> specific PR is a very valuable addition to a PR. The candidate could >>>> be a great help for that! >>>> >>> >>> Yes, great point to clarify. By "address" we mean either take care of it >>> themselves if it is in their purview or work with the maintainers and >>> support maintainers with setting up priorities/getting additional resources. >>> >> >> Exactly what Ewa said. The person is meant to be an asset to the team to >> help us keep this project running as smoothly as possible. As of right now >> our massive PR backlog is the obvious sticking point we have and so that's >> what the SC wants to see tackled first. >> >
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/I2LS2DXD5GAJ34IPR3DCSIEGDLYVODRB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
