Congrats Łukasz! :) On Mon, Jul 12, 2021, 11:44 AM Ewa Jodlowska <e...@python.org> wrote:
> 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/ >
_______________________________________________ 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/ML44YWJOHYENQ3L5SGJNIK53J27MXTW6/ Code of Conduct: https://www.python.org/psf/codeofconduct/
