Hello everyone!
I would like Django to start using some form of automatic checker for stale PRs. I did some investigation and there is a GitHub Action that would provide this functionality for us:
Any objections to try it out and evaluate how that works for us?
Thanks!
Natalia.
Iād kind of say itās up to you and Mariuszā¦ ā itās you two that have to run the repo.
Iām sceptical of the value myself. When it was added to the django/djangoproject.com repo I just had to more or less fight it saying āHang-on, donāt close that!ā (Sure we did close some, but I could have just sorted by least recently updated and looked at the first page for equal results.) (Part of the issue there may have been that the defaults are too aggressive for an open source project.)
I agree that we should tweak the default, particularly I think that the 60 days for automatically adding the āStaleā label is a sane default but closing 7 days after that is too aggressive. I would suggest we set 30 days after setting the label, to allow for holidays/DjangoCons/etc to happen in between and not have automatic closures.
I think itās rather unfriendly to use bots, especially on PRs that didnāt even receive a response from a human. I raised a previous object to using it for djangoproject.com. I would say it takes a minute or two to look at a PR and evaluate what should be done. Sometimes work takes a while, with periods of inactivity, and there is value in keeping old PRs open so we donāt create duplicates with feedback and history split between locations. If having a lot of old PRs open bothers you, just ignore them. 
(But seriously, what would it accomplish? Do you feel overwhelmed by the backlog?)
I share your opinion
This is a valid point, and I appreciate you bringing it up. I was contemplating a scenario where PRs would be marked as āStaleā if a reviewer requested feedback from the author and received no response within a specified timeframe, for example (currently these are the many comments āHello @author, would you have time to keep working on this?ā).
I read this post and while I agree with your rationale for (not) automatic closing old issues (since they may very well be still valid), I also agree with Sarah in that the automatic flagging of Stale PRs makes more sense, which is what Iām proposing in this post (āThere are configurations around stale PR closing which I think makes more sense in general ā¦ , as other people might be reluctant to work on something if there is an open PR and it prompts someone to decide if they want to come back to this if they have just forgotten for example.ā).
I donāt agree with this sentence; it feels like an oversimplification of the process. At least to me, this takes around 15-30 minutes per PR. The process involves reading the linked ticket and its comments, the PR history, and general PR comments. Then, reviewing the non-resolved inline comments and identifying who is who (authors vs reviewers). This also includes assessing whether there is a pending need for agreement or if there was an agreement that was not pursued. The next step is the evaluation of whether whatever is left is worth completing using fellowās time or if we should ask the author whether they have time/interest in pushing the work to the final line. I usually opt for the latter to encourage community participation. However, this means I need to remember 15 or 30 days later to come back to these PRs and close them (or complete the work if it makes sense).
I donāt disagree with this sentence but from my observation of current practices (and this is where I may be over simplifying), it seems that is preferred to be a bit more aggressive with closing PRs, so (new) contributors can more clearly see where there is work to do and can pick up where others left (it seems to be a bit easier for people to build on an existing stale PR than starting from scratch).
It doesnāt bother me, and this isnāt a matter of personal taste or preference. My intention was to contribute to the overall health of the Django project from the perspective of my role as a fellow. Additionally, given that the fellows invest time in pinging and closing stale PRs, I thought we could allocate those minutes to other, less automatable activities, such as reviews of active PRs.
I donāt personally experience this, but I believe others might. New contributors, eager to help as we encourage in the Contributing guide, may feel lost and overwhelmed when confronted with the sizable open PRs queue. Questions may arise on where to start ā should it be the oldest, the least recently updated, or the smaller ones? They might also wonder āWhy are there so many open PRs? Is this a community that doesnāt pay attention to contributions?ā
In any case, your message helped me realize that I could tailor my proposal a bit more for the sake of clarity. If the initial interaction with the bot is an issue (and I agree it is), we could tweak the process as follows:
Thanks! Natalia.
This isnāt a bad idea at all. In general folks canāt close a PRāthey donāt have permissionāso even if they take a look, and think āthis is outdatedā, it still needs a Fellow to follow up and close it. If a comment, like the buildbot ones could apply a label, then that could be acted on (automatically or not), which brings PRs closer in-line with Trac (where anyone can make edits, and help triage).
Iām much more sympathetic to something along those lines than just the Stale bot, which, repeating myself 
, it a bit blunt
TBH, I donāt like bots (unpopular opinion) and they seem unnecessary at our scale (~150 open PR). I offen struggle with closing old PRs because I have a gut feeling that something more needs to be said (more feedback etc.) and I donāt want to be forced to make decision faster because a soulless bot will push me.
My 2Ā¢.
Thank you everyone for their feedback.
Iāve been thinking about this and I acknowledge the mentioned counterpoints, thanks for raising those.
I still think that some form of automation would be beneficial, what would you think about a reminder bot? That way people could implement their own flow, for example a flow that I would find very useful is:
Then, there a are a few alternate derived flows. Sometimes I then get immediate responses with fixes, which Iāll review/evaluate/comment back, or Iāll get responses saying āIāll be slow because this and thatā so I could reschedule the reminder to happen in a month or so. Eventually this could lead to PR closing (by a human) but with the benefit that ātime accountingā would be done automatically.
Or, I may want to re-check a PR in 3 or 4 weeks because there is a release in between, or a conference, or similar.
Iāve found a few GH actions that act as reminders creator/reminder poster, though the process of āresetting a reminderā may need to be done manually (removing a label).
Would this be of interest of anyone else? I know itād definitely help my flow but I wouldnāt want to push this setup if itās only appealing to me.
Thank you!
Natalia.
Hello everyone,
Iām keen to push some of this forward. Concretely, what I would like to do is:
In all cases, no bot would be closing a PR, always a human would (when necessary).
My main aim with this (and similar ideas) is to make it easier for reviewers/fellows to manage PRs (and their time!) efficiently. Itās also about helping contributors follow the correct process without bombarding them in lots of links to docs. In my view, sending contributors to read a lot of docs can be less user-friendly than giving them prompt and clear messages about the next steps. This helps set everyoneās expectations correctly, IMHO.
Natalia.
PS: When searching for existing options, I found this issue which describes a flow very similar to what Iād have in mind.
My ideal django helper bot would be a weekly job that checks django PRs that havenāt had activity (commits or comments) in 2 months and are not in the review queue (using the PR title to get the ticket number and skipping ones that donāt have this). Then it has an automated message saying something like: āAre you still working on this? This isnāt in the review queue - if youāre waiting for a review please check that the ticket has āpatch needs improvementā, āneeds testsā, āneeds docsā set to False and āhas patchā set to True.ā and it labels the PR something like āstaleā.
Then anyone in the community can check the stale PRs that have had no updates either on Trac or the PR after maybe 2 weeks and close with a message that they can reopen. Or, if itās clear that they are actually waiting for a review but forgot to update Trac, we do this.
As a meta comment, if the automation will:
Then I think we should do it, it can always be improved based on feedback or reverted if it causes problems. 
What you describe here sounds quite reasonable to me @nessita.
Itās also the case that youāre in charge (for some itās not a dictatorship value of that) Itās you that has to run the repo now. So if you want to give it a go, Iām happy to put a +1 here.
Good hustle! 
Iām giving the add/get reminders a go, I have proposed two new GH actions in this PR: Added GitHub Actions to create and check for reminders in pull requests. by nessita Ā· Pull Request #17852 Ā· django/django Ā· GitHub