Locking pull requests makes archeology harder

[indygreg]

Description

It appears this project locks some pull requests and issues (these are essentially the same thing internally to GitHub) as resolved upon close/merge. This behavior can make code archeology harder.

For example, I filed #11146. It referenced #10560. But if you go to the timeline of #10560, there are no events for this reference since the PR was locked in April.

I understand the need to lock issues/pull requests in order to prevent abuse. I also understand why it is desirable to avoid comments on a closed pull requests.

However, by locking a PR/issue and preventing the GitHub timeline from having any subsequent updates, this prevents future references to the issue/PR from appearing. This in turn makes it harder to follow the impact of a PR/issue within this project and across the broader software ecosystem. And this can make lives for developers harder by making it more difficult to discover knowledge. Without breadcrumbs in the issue/PR timeline, you have to resort to a broader search, which is far less targeted and often takes longer.

Maybe this is a feature and is working as intended. There are certainly benefits of this approach! But I thought I'd share my negative experience in case there is room to consider a change in behavior.

If this feature is marked as a dupe, I think it reinforces my point: I tried to search for an existing report for this (as I'm sure it was discussed somewhere) but GitHub search is not terrific.

Expected behavior

If GitHub allowed you to prevent comments but allow timeline updates, this seems strictly better. In the abuse scenario, you could still lock everything. But in the common scenario where you just want to prevent future discourse on a closed issue, you could still facilitate archeology via references in the timeline. I have no clue if GitHub supports granular locking though.

pip version

n/a

Python version

n/a

OS

n/a

How to Reproduce

Use GitHub

Output

n/a

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[potiuk]

To be hones (as a casual user) this looks like you chose a wrong forum to ask it. Probably you could ask the same question in about a few hundred of projects on Github, Maybe you can ask there if such feature is available, advocate for it and come back here if you find that it's there. I think it is sensible thing to do to help the maintainers here.

1. you have a problem
2. that depens on Github configuration
3. and yet you expect that somebody else will check if your proposed solution is avaiilable in GitHub
4. while you admit yourself that you've made 0 effort to check if what you want is available

This is almost as if you are demanding maintainers of the project to do the job for you. Not very helpful to anyone and showing about 0 empathy for people who are trying to develop one of the most important pieces in Python infrastructure for free.

I suggest that you go and make your research and come back here with results if you find it is possible, or make GitHub add such feature. That would be the most sensible way to help maintainers here to their job and pay back for the software you are using without paying for it. One of the best contributions I could imagine for person like you who not only have the need but also deep understanding of the consequences of current lock functionality. I think you discussing it with GitHub would be the best use of your skill and knowledge.

[pradyunsg]

If GitHub allowed you to prevent comments but allow timeline updates, this seems strictly better.

It does not.

I have no clue if GitHub supports granular locking though.

It does not.

---

The locking automation exists to reduce the amount of effort that the maintainers have to put in, to maintain this project's issue tracker. This project is popular enough that individuals will comment on random issues asking for help, or clarification on the behaviour introduced in that PR (which made is basically impossible to maintain the issue tracker/keep up with incoming comments). This is expecially annoying when it's, as an example, a multi-year year old PR and the person claims that the change broke them, and thus should be reverted.

The amount of such users drastically reduces when the PR is locked and users need to file an issue for this, which also reduces the toxicity of the interactions since they need to provide details and (generally) people put in effort to sound coherent in such cases.

Yes, it's annoying that it's not possible to get issue updates on closed PRs. I think it's a worthwhile tradeoff. In situations where someone thinks it's valuable to have the history show up, the maintainers can unlock and relock the issue/PR, which is what I've done in that case.

I don't think there's anything else actionable here beyond reaching out to Github with a feature request. I've done that in the past, and if someone else wants to, please feel welcome to do so.

[indygreg]

Despite being a frequent GitHub user and maintainer of some somewhat popular (but not as popular as pip!) projects, this behavior was surprising to me!

The points you make about trade-offs all seem reasonable to me. Price of success, I suppose.

Thank you for taking the time to provide a thorough answer.

[pradyunsg]

See also #6563 (comment), from back when this stuff was enabled (it had caused notification spam).