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/6D7QLC527K6FGPPLOMQMUDKHWYV7WJAU/ Code of Conduct: https://www.python.org/psf/codeofconduct/
