Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locking pull requests makes archeology harder #11149

Closed
1 task done
indygreg opened this issue May 26, 2022 · 4 comments
Closed
1 task done

Locking pull requests makes archeology harder #11149

indygreg opened this issue May 26, 2022 · 4 comments
Labels
type: bug A confirmed bug or unintended behavior

Comments

@indygreg
Copy link

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

@indygreg indygreg added S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior labels May 26, 2022
@potiuk
Copy link
Contributor

potiuk commented May 27, 2022

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
Copy link
Member

pradyunsg commented May 27, 2022

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
Copy link
Author

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
Copy link
Member

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

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 28, 2022
@pradyunsg pradyunsg removed the S: needs triage Issues/PRs that need to be triaged label Mar 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

3 participants