Can we be more "aggressive" and say that if the contributor hasn't shown any sign of activity for more than a month (whether it's a reply to a question, or just a commit), it is safe to shorten the wait?

I have often seen contributors claiming "I'll do it soon" but actually not do it.

Also maybe explicitly say that this can be bypassed for sprints, where waiting 1 day isn't an option?
CC @reshamas

How's this:

A good etiquette for this is:

To determine whether a PR is active or stalled, ask the contributor if they plan to work on the PR in the future.

An example is:

It would be great if you could follow up on the work that you started. Please indicate if you will continue to work on it. Refer to the Stalled pull requests section
in the Contributing Document.

A "dynamic activity" is defined as one which moves the PR forward such as a commit or reply to a question. A "static activity" is one which does not, such as a status update.

Failure to respond within a week with a dynamic activity implies that the PR is stalled.

​For PRs which have not shown any type of activity for at least a month, the ​allotted timeframe for a dynamic activity is three days.

For PRs which are submitted during a sprint, it is expected that dynamic activity will take place during the sprint duration. Follow-up time frames post-sprint may be determined and adjusted by the sprint organizers.

I was more concerned about the possibility of picking up a stalled PR during a sprint, not about stalled PR that were submitted by sprint attendee (even though that's also an issue).

Sticking to the current text, sprint attendees would have to wait one day at least for the original contributor's response before working on a stalled PR, which doesn't make sense since sprints are often one-day long.

how would we know if a PR is stalled during a sprint?

I like that. It'd be nice if organizers tag those PRs with a "Sprint" tag.

How about (that keeps it quite simple):

Failure to respond within 2 weeks with an activity that moves the PR forward will result in tagging that PR with "help wanted".

Follow-up for un-merged sprint PRs will be communicated to participants at the sprint, and those PRs will be tagged "sprint"

I tried to include a summary of this discussion in the PR (keeping it short). I felt that it was important to explain what tagging "sprint" meant. I am not sure that I fully captured the essence of your thoughts @reshamas , feedback welcomed.

@GaelVaroquaux This works. I agree, shorter is better.

Thanks a lot for this fruitful discussion.

If appropriate? Sometimes the old PR doesn't contain anything useful, in particular if the issue has been misunderstood.