I hope even you would agree that simply increasing the length of time or number of interactions is not automatically a benefit in all cases. It’s true that avoiding super-rapid approvals and requiring a few interactions may be useful to slow down people trying to pull a fast one. But when the lag time between responses is already on the order of months, I don’t see that increasing it even more really serves that purpose. Presumably no one thinks it would be good to increase response times to 10 years just because “it takes longer” is a benefit.
I guess the question I have after reading this thread is: is there any action other than “the PSF funds someone to handle this full time” that can improve matters? If not, I don’t see much point in further discussion. If so, what concrete actions can be taken, by someone not currently already overloaded with this kind of work, that would improve things?
This seems to be the right answer to me. Maybe make it mandatory above a certain download rate of packages if you’re concerned about high value targets. This reduces the total load to active users who truly benefit from this rather than a blanket policy. I haven’t looked at the statistics but if 80% of packages are of low download counts, does the workload burden really justify the arguably marginal security benefits? While 2FA is a solid improvement, it can be a marginal value add in cases where it’s not protecting something of value to the community.
I have been told by you some things, absolutely, but I don’t think you speak for the community at large, because the Python community is a nice community that welcomes contributions for open source projects and dig into this kind of issues, and because we do have a problem here. Your explanation that taking months to operate a conversation to increase security is not very convincing. In my opinion, it’s just a lack of resources and unwillingness to improve the process and see how it can be delegated because they wait for a new hire.
You should not focus on me, but on the process and how we can improve it. I would be very curious to get your detailed feedback on my PR and why it’s not an improvement. Of course if it’s just because
“my help is not welcome” because I am not a security expert, yeah I am unwilling to accept that answer.
But I will give you one thing: my help is indeed not welcome because it undermines the ask for a paid staff and they don’t want to improve the process in the interim. And that is what is wrong IMHO.
If help is unwelcome, why do we have the ability to propose some PRs? If it’s closed to the community, let’s make it clear.
@tarekziade You seem to have latched onto a conspiracy narrative regarding holding process improvement work hostage for a PSF hire but I think you are veering into mis-representation. What as was said was:
I won’t commit to clearing it as I do not have time, and it undermines the requests I have made for a paid support role for PyPI internally at the PSF year over year
This reads only as a statement regarding one individual’s choices regarding their personal time, and then only with respect manually triaging existing issues using existing process. The afterthought reads only as a sad observation [1]: in the current environment, the only reward for short term triage is more long term triage—a choice exactly no-one would want to make.
Well, I am just to a point where I really don’t understand why we can’t move forward to improve things together, and what drives this behaviour that is completely weird to me. e.g. complaining of a lack of resources and not trying to leverage the help of the community, and acting like they are facing angry customers.
I guess I was spoiled in every other project in the Python ecosystem (including ones about security because the whole argument about not being able to delegate some peripheral tasks is a myth - there are always stuff anyone can do).
my approach will be to continue providing ~1 hour of time per friday until the un-triaged list is all requests younger than two weeks.
once there are only “young” untriaged requests, i will begin processing the requests with valid recovery codes. as is, requests with valid recovery codes are being deprioritized. i’d estimate that this will begin in march 2024.
i’m continuing to provide ~1 hour of time per friday until the un-triaged list is all requests younger than two weeks.
once there are only “young” untriaged requests, i will begin processing the requests with valid recovery codes (currently 65 such requests exist). as is, requests with valid recovery codes are being deprioritized. i still estimate that this will begin by march 2024.
as an additional update, internal discussions have re-commenced regarding hiring paid staff for pypi support requests. there is no commitment yet but a proposal and job description will be developed next week for consideration, and hopefully approval.
i will continue to provide ~1 hour of time per friday. now that there are only untriaged requests, beginning next week i will begin processing the requests with valid recovery codes (currently 80 such requests exist) with remaining time after addressing new untrained requests in first-in-first-addressed priority.
With building a large community comes responsibilities. If PyPi folks feel they are short handed, they can alway rely on folks like me. We are here to help. As a PyPi advocate, this is the first time that I see users being blocked for weeks (or even months like Tareq above) which is absolutely against any definition of high standards for a successful community like PyPi.
Hi @ashahba, I think to be fair to the good folks supporting PyPI here, 3 weeks is not a long time for a recovery of an account with that many heavy packages. You’ve had a first response already last week, and replied to that 5 days ago. Now you are waiting for another reply. I’m not sure about the exact timeline, but days to a few weeks between replies doesn’t seem unreasonable.
Now that you are here: you also have a responsibility to PyPI to keep the load you put on PyPI reasonable. Among the packages you own is the number one user of space on PyPI, tf-nightly-intel (see Statistics · PyPI, it uses 325 GB right now). I don’t know if you received the request from the upstream Google TensorFlow team (from this comment: Those builds are not published by the TF DevInfra team and rather by partners. We will bring it to their attention and look to have them remove older nightlies like the official tf-nightly does), but please implement a cleanup mechanism for those nightlies.
And now that I’ve touched on this topic: the support requests for limit increases are also quite backed up. Once in a while I help triage those, because the first response can often be done without needing a PyPI admin, and just knowing the process helps either closing some invalid requests or make the requester add needed info so the admins can decide. My triaging usually happens when I’m getting a question from a project maintainer whose releases are blocked. It’d be great if those requests could get a bit more attention as well. Unlike account recoveries they’re not due to “user error” but only due to using PyPI as it’s meant to be used. Here is an example of a request that is almost 3 months old, for a very popular package (JAX) that now has to delete old releases to make space for new ones: Project Limit Request: Jaxlib - 50 GiB · Issue #3417 · pypi/support · GitHub.
i will continue to provide ~1 hour of time per friday. now that there are only untriaged requests, i have begun processing the requests with valid recovery codes (currently 60 such requests exist) with remaining time after addressing new untriaged requests in first-in-first-addressed priority.
meta-update: i am submitting a funding proposal for the paid PyPI support role today.
Please read the rest of the thread, including the latest update from Ee right above your posts. It seems like it’s been made pretty clear what the process is and what progress is being made. You’re not helping by constantly pinging here and in your support ticket, they’re already well aware.
i was out sick last week and was overwhelmed the week before, but i will continue to provide ~1 hour of time per friday. i have begun processing the requests with valid recovery codes (currently 50 such requests exist) with remaining time after addressing new untriaged requests in first-in-first-addressed priority.
meta-update: funding proposal for the paid PyPI support role has been approved and the PSF is working on getting the job posting up and promoted.
i will continue to provide ~1 hour of time per friday. i am continuing to process requests with valid recovery codes (currently 37 such requests exist) with remaining time after addressing new untriaged requests in first-in-first-addressed priority.
