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