Discussion on the use of the "lock" bot

[KOLANICH]

• They cause bloating of the bug tracker with duplicates (if an issue is locked, people will have to create duplicates) of the same issues which will cause problems with search.
• These duplicates are poor because the old discussion are left in the old locked issue.
• Using these bots and locking issues, especially for the cases without harsh vandalism by highly motivated vandals who are ready to register multiple accounts specially for that, especially locking issues automatically with such causes as "no activity", is disrespect to anyone leaving issues and comments in such an issue tracker because they cannot edit their messages once the issue is locked and because they have spent some time writing the text and locking an issue with the advice "start from scratch" is in fact wastes all their efforts on writing comments.

[asottile]

my 2c, I'm more annoyed about the massive amount of email spam I'm getting from merged and fixed PRs that I've participated in

if it's going to lock stuff I really don't care, just please don't leave a comment and spam my inbox. the comment is non-actionable as well (it's locked!!!)

[xavfernandez]

After roughly 1400 mails from lockbot (and roughly 4400 to come), I think we should disable the auto-comment.
We'll lose the lock explanation but we could add a warning to pip's README.rst.

[asottile]

@andreymal I believe we're discussing lockbot which locks already-closed issues with no activity. From what I understand the bot you're talking about is stalebot (which I assume will still produce a comment when closing an inactive open issue)

[andreymal]

@asottile (I misread the text, ok)

[xavfernandez]

#6564 was merged to stop the notification spam.

[pradyunsg]

We should add that back once it catches up though. The explanation is a useful ting here.

[xavfernandez]

@KOLANICH I don't see the point of mentioning stale-bot here ?

[KOLANICH]

Every bot forcing issue creators and commenters to post junk messages into issues in order to just satisfy a bot are disrespect to everyone visiting that bug tracker.

[pradyunsg]

pip doesn't use stale bot. If you have issues with it, bring them up elsewhere.

[KOLANICH]

pip doesn't use stale bot.

This is good.

[pradyunsg]

Since there's multiple people telling us to stop using a lock bot, lemme type a long comment on my phone at 1am to try to bring everything in my head in one place.

The main reason for locking old and closed issues in pip's tracker is to ease the maintainance overhead. I'm pretty sure that (outside of the notification spam), pip's maintainers do view these bots as a net positive. I'll elaborate.

Very often, users comment on really old issues asking for support claiming it's the same problem when actually it isn't. This is especially a problem because they comment without providing enough context (which is explicitly asked for in the issue template for new issues) and even when it is, it's usually easier to deal with it when it's a dedicated request.

It's useful to have them create a new issue, ideally linking to the old one. It's not a high bar and if it trims down the number of support requests, I'm OK with that. It's a lot easier to keep track of support requests when they're open issues and can be actively triaged more easily.

I have not seen the creation of sub-par duplicates and we can decide what to do for that if it becomes a drain. Right now, I think just adding a #-number is enough to make it visible from the closed issue. And a maintainer can comment on the locked issue if need be. If that's a bottleneck? Well, then there's not enough man-hours in the project to deal with the issue tracker and this becomes a symptom of that problem. I see that as a win especially since I don't expect there to be too many issues of this kind.

Not sure what OP's vandalism point is so can't really respond to that.

As a reminder to anyone reading this, the issues that are being locked are closed issues that have been idle for > 30 days. If you really think there's value in keeping them open as a channel for users (often for support requests, that probably won't provide enough information in the first place) and somehow requiring them to open a new issue is too much effort... I (and other pip maintainers/contributors) have to deal with it and it is a non-trivial amount of cognitive overhead.

If you're going to make a case for removing the bot, I welcome you to. However, I'd prefer that you think about what alternative can be used to using this bot for this specific problem. The whole point is to make maintaining this project less painful (especially given the fact that now we just caused so much churn for our existing contributors). If your suggestion does the opposite of that, it's not a viable option.

I'm frustrated enough already with allegations of this being a political move to less openness/censorship and stuff like that, so, just please be nice and don't add to it.

---

On a somehow related note, let's only discuss bots pip is actually using.

[dstufft]

From a practical standpoint, if an issue is closed and someone finds a way to retrigger it, they can't actually reopen the issue themselves. The best they can do is comment and hope a maintainer notices and reopens. It's actually better IMO for even actual recurrences of the same issue to generate a new issue, because that isn't going to get lost in the shuffle.

[KOLANICH]

As a reminder to anyone reading this, the issues that are being locked are closed issues that have been idle for > 30 days.

There is a problem with this reasoning. Issues often stay open and idle for years, because everything, that the commenters, who were present that time, wanted to be discussed had been discussed, but noone had implemented the feature because of lack of manpower. It doesn't mean these issues should be either closed or locked or both. It doesn't mean that the issue should be marked as "wonttfix, we have not implemented it within the deadline, so we will never be able to implement it, so wontfix". It doesn't mean that everyone who has some information related to that old issue must shut up.

Very often, users comment on really old issues asking for support claiming it's the same problem when actually it isn't. This is especially a problem because they comment without providing enough context (which is explicitly asked for in the issue template for new issues) and even when it is, it's usually easier to deal with it when it's a dedicated request.

This is definitely a possible and unavoidable situation.

It's useful to have them create a new issue, ideally linking to the old one. It's not a high bar and if it trims down the number of support requests, I'm OK with that. It's a lot easier to keep track of support requests when they're open issues and can be actively triaged more easily.

It just trades one problem for several other ones. IMHO - more harsh ones.

[pradyunsg]

Issues often stay open and idle for years

The bot only locks closed issues. Please, look at the behavior of the bot or read the text you quoted again.

You're mixing "stale" with "lock".

[KOLANICH]

This was just an example explaining why deciding if an issue should be locked basing on its idle time is a bad practice: idle time says nothing about if an issue still actual, it says only about idle time. So, depending on the project policy, it may make sense to either lock closed issues immediately (the reasoning is as follows: "the issue has been closed, this means we consider it as solved/decided/etc, so there is nothing to discuss here anymore, so in order to reduce our cognitive load we lock it"), or not to lock at all.

However, I'd prefer that you think about what alternative can be used to using this bot for this specific problem.

Unsubscribe button is a solution, I guess.

[pradyunsg]

What is your underlying concern with locking of issues? Do you view that as censorship? I can see why you view "stale" as not a good idea but "lock" is a different bot with a completely different heuristic.

FWIW, what do you view as the ideal outcome of this discussion?

[cjerdonek]

So, depending on the project policy, it may make sense to either lock closed issues immediately ..., or not to lock at all.

@KOLANICH One advantage in my mind to not locking immediately when an issue is closed is that it gives people a chance to ask that the issue be re-opened. If it were locked right away, people wouldn't have an easy way to do that since locking prevents people from commenting. So rather than viewing the 30 days as "idle" time, maybe a better (or at least another) way to look at it is as a grace period to let people ask that the issue be re-opened. Does that make sense?

[cjerdonek]

@pradyunsg In response to @KOLANICH's comments, would it be possible to have GitHub display a message or box of some kind when an issue is closed saying, "this issue has been closed and will be locked in X days if there are no additional comments." That way people won't be caught by surprise and will have a way to know to ask that an issue be reopened before it's too late.

I think @KOLANICH's point is that a 30-day "idle" period seems arbitrary and doesn't have a clear purpose -- if the issue is closed, why is the project allowing any comments at all? I think if the 30 days is reframed as a grace period to let people ask for an issue to be reopened (e.g. using a message box like I've suggested), then that could help make the rationale for the policy clearer.

[pradyunsg]

We can add a bot that makes a comment when an issue is closed about this or we could document the rationale for the bots somewhere in our contributing documentation.

I prefer the latter obviously but I'm cool with both.

[pfmoore]

I'd prefer not to get more notifications when issues are closed (which is what adding a comment does). Like @pradyunsg I'd prefer it if we simply added this to the docs.

[KOLANICH]

What is your underlying concern with locking of issues?

several concerns for me.

1. when I create an issue I search if such an issue has been reported. If I see too many issues in search results (more than 1 page), I don't visit any of them to check, if the title all of them doesn't look very matching, and just make an new issue. It is a positive feedback loop triggered on the treshold of 1 page. I think anyone else will do the same. If you force people to create a new issue for already discussed topics, the bug-tracker will be junked with dupes, both forced and non-forced ones.

2. I cannot fix typos I spot in my old messages sometimes (I never proofread them before posting, but if see a typo or any places I can improve, I usually fix them) if the message is in a locked issue.

3. I cannot argue that an issue has been mistakingly closed.

One advantage in my mind to not locking immediately when an issue is closed is that it gives people a chance to ask that the issue be re-opened.

I don't understand. If ones want to encourage people to ask an issue to be reopened, if the people feel like that, the issue should not be locked at all and people should be able to do it even years after it had been closed. Otherwise the sentence is final and no arguing is encouraged because reading it is "cognitive load". This way all these issues should be locked immediately after closing. I don't understand any tradeffs between these ways, like 30 days or 1 hour. Essentially it is allowing some people to comment only because the time they came to an idea to add there some comment (a random variable IRL!) is within some range.

[cjerdonek]

I'd prefer not to get more notifications when issues are closed (which is what adding a comment does).

I was asking about the possibility of having some kind of message or box that displays at the bottom that isn't a comment. That way people looking at the issue will see it without having to know about the docs or that there is a section in the docs about what happens to issues. For example, my latest PR says this at the bottom, which isn't a comment:

Add more commits by pushing to the make-test-package-finder branch on cjerdonek/pip.

The CI system also has an associated box of information that is dynamically generated (namely the result of the various checks that have run). If GitHub allows it, perhaps the message could even dynamically display the number of days before the issue will be locked.

[pradyunsg]

would it be possible to have GitHub display a message or box of some kind when an issue is closed saying, "this issue has been closed and will be locked in X days if there are no additional comments."

No, AFAIK.

---

We can't do that for PRs via PR checks, as you suggest, since they're only triggered on changes to the PR.

[xavfernandez]

The addition of the lock-bot has been approved by 4 of the active pip maintainers in #5186.
Now that the main pain point of the spam has been dealt with, it is unlikely to be removed immediately: I think we'll give it at least a few months to see how it goes.

[pradyunsg]

I'm going to go ahead and close this issue now, in accordance to what @xavfernandez said.

If someone would file a new issue/PR to document the policy of locking the issues somewhere in our development guide, that'd be great!

[cjerdonek]

t's useful to have them create a new issue, ideally linking to the old one. ... I have not seen the creation of sub-par duplicates and we can decide what to do for that if it becomes a drain. Right now, I think just adding a #-number is enough to make it visible from the closed issue.

FYI, I noticed that "back links" don't seem to show up on locked issues when linking to a locked issue. (I noticed this when linking to #6142 from #6587.)

[pradyunsg]

Oh, that's not good. :/