Call for resumes: Developer-in-Residence to support CPython
Hello!
Through a collaboration, the PSF and SC scoped the role for a Developer-in-Residence. We are now accepting resumes -- see below for details.
I am super happy to finally set this in motion! If you have any questions, don't hesitate to reach out. Ee and I are on apply@ so feel free to send questions there as well. A blog will be posted later today informing the community.
The Python Steering Council and the Python Software Foundation are looking to hire a Developer-in-Residence! Background
CPython, the reference implementation of Python, is developed and primarily maintained by volunteers.
Inspired by the Django Fellowship Program's success ( https://www.djangoproject.com/fundraising/), the PSF has strategically planned to support CPython in a similar way beginning this year. Thanks to the support from sponsors such as Google, this effort is moving forward.
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. Job Description
This Developer-in-Residence will continually coordinate with PSF staff and the Steering Council on the following tasks (note: this is not an exhaustive list of all tasks, but an overview of desired outcomes):
Create metrics based on:
Surveying maintainers and community to capture:
-
a directory showing who maintains what standard library module
-
interest in maintaining standard library modules
-
which standard library modules are most important to users
-Combine usage and surveyed metrics to determine which standard library modules need help and what the maintainer cost is for standard library modules
Determine additional intersections of data that could be useful
Address Pull Request and Issue backlogs based on the developed metrics and other metrics created by the Steering Council
Create a long-term plan for addressing the backlog
-
Review personally pull requests & triage issues
-
Help coordinate core developers/maintainers of specific modules to
review pull requests and triage issues
-Help maintaining, improving and stabilizing the CPython test suite, including the continuous integration infrastructure and buildbot fleet.
Attend Steering Council meetings quarterly and have regular communications with the PSF staff
Organize virtual sprints (i.e., at PyCon US) to collaborate with other Python core developers to grow the community of Python core developers and simultaneously close a large number of existing issues and pull requests
Provide transparency by proposing and fulfilling a public record as agreed to by the Steering Council and PSF Staff
Publish two blogs on pyfound.blogspot.com throughout the year informing the community on progress (halfway through and at the end of the residency)
Necessary skills
Strong project management skills
Must be very organized and detail-oriented
Experience working with CPython volunteers
Excellent written and verbal communication
Experience working with software development teams remotely
Ability to balance demand and prioritize
An active maintainer of CPython is preferred. Interested in this position?
If you are interested, please send an email to apply@python.org with your resume (please include community contributions). The call for resumes will be open until May 16, 2021, AoE.
Employment/vendor arrangement will depend on whether the person resides in or outside of the US.
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?
On Mon, Apr 5, 2021 at 7:30 PM Ewa Jodlowska <ewa@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?
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.
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!
Victor
Night gathers, and now my watch begins. It shall not end until my death.
On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner <vstinner@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 <ewa@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 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.
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.
On Mon, Apr 5, 2021 at 12:57 PM Ewa Jodlowska <ewa@python.org> wrote:
On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner <vstinner@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 <ewa@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.
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 ewa@python.org
On Mon, Apr 5, 2021 at 4:00 PM Brett Cannon <brett@python.org> wrote:
On Mon, Apr 5, 2021 at 12:57 PM Ewa Jodlowska <ewa@python.org> wrote:
On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner <vstinner@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 <ewa@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.
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 <ewa@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 ewa@python.org
On Mon, Apr 5, 2021 at 4:00 PM Brett Cannon <brett@python.org> wrote:
On Mon, Apr 5, 2021 at 12:57 PM Ewa Jodlowska <ewa@python.org> wrote:
On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner <vstinner@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 <ewa@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.
On Jul 12, 2021, at 11:42, Ewa Jodlowska <ewa@python.org> wrote:
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!
I am very excited by this announcement. Thanks, Łukasz, for applying and thanks, to the PSF and the Steering Council, for securing the funding and making this wise choice. Having a developer-in-residence has the potential to make a huge positive impact on many aspects of CPython and I believe Łukasz to be one of the most qualified people for the job. I have had the privilege of working closely with him on the CPython Release Team over the past three and a half years and have come to greatly respect his technical skills, his judgement, and his obvious passion for Python. It's been a pleasure working with him so far and I look forward to his contributions in this new role over the coming months.
Woot!
--Ned
-- Ned Deily nad@python.org -- []
On Mon, Jul 12, 2021 at 10:42:45AM -0500, Ewa Jodlowska wrote:
Just to circle back, we have officially contracted with Łukasz Langa to be the first CPython Developer-in-Residence!
Congratulations, Łukasz!
I read your blog post in your decision, and it is great that you are stepping in contribute full time, for Python, yourself and the analyze the future of this program.
Also, thank you Ewa for your contributions to PSF!
Thank you, Senthil
Congrats!
Warm Regards Dong-hee
2021년 7월 13일 (화) 오전 12:45, Ewa Jodlowska <ewa@python.org>님이 작성:
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 <ewa@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 ewa@python.org
On Mon, Apr 5, 2021 at 4:00 PM Brett Cannon <brett@python.org> wrote:
On Mon, Apr 5, 2021 at 12:57 PM Ewa Jodlowska <ewa@python.org> wrote:
On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner <vstinner@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 <ewa@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-leave@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/I... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Tue, 13 Jul 2021 at 01:44, Ewa Jodlowska <ewa@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!
Likewise - this is excellent news!
For those interested, Łukasz has a detailed post (linked from the PSF one) that goes into his understanding of an plans for the role: https://lukasz.langa.pl/a072a74b-19d7-41ff-a294-e6b1319fdb6e/
(Super short version: the focus of the paid Developer-in-Residence time is to facilitate activities that aren't already receiving dedicated core developer time through other means; Łukasz has already been seeking advice from the current Django Fellow on applying the lessons they've already learned to the CPython experience)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Congrats Łukasz! :)
On Mon, Jul 12, 2021, 11:44 AM Ewa Jodlowska <ewa@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 <ewa@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 ewa@python.org
On Mon, Apr 5, 2021 at 4:00 PM Brett Cannon <brett@python.org> wrote:
On Mon, Apr 5, 2021 at 12:57 PM Ewa Jodlowska <ewa@python.org> wrote:
On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner <vstinner@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 <ewa@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-leave@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/I... Code of Conduct: https://www.python.org/psf/codeofconduct/
participants (9)
-
Brett Cannon -
Dong-hee Na -
Ethan Furman -
Ewa Jodlowska -
Kyle Stanley -
Ned Deily -
Nick Coghlan -
Senthil Kumaran -
Victor Stinner