Congrats Łukasz! :)
On Mon, Jul 12, 2021, 11:44 AM Ewa Jodlowska 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 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
>> [email protected]
>>
>>
>> On Mon, Apr 5, 2021 at 4:00 PM Brett Cannon wrote:
>>
>>>
>>>
>>> On Mon, Apr 5, 2021 at 12:57 PM Ewa Jodlowska wrote:
>>>
On Mon, Apr 5, 2021 at 2:36 PM Victor Stinner
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 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
