The msftbot account locking conversations is annoying

[0xced]

Often I come back to some (not that) old issues or pull requests and would like to add some additional information. Unfortunately, it has become impossible lately because @msftbot is aggressively locking conversations.

For example, in the msbuild repository, I was able to add a for the record comment more than two years after the last activity on the issue: dotnet/msbuild#539 (comment) This comment received 2 👍 so I guess it was somehow valuable.

Today I came back to an old pull request of mine (#35183) and wanted to add this additional information:

For the record: while this particular pull request has not been merged, an equivalent pull request (#51713) has been merged and has shipped as part of the .NET 6 release.

But it is impossible because the conversation is limited to collaborators. This is juste one particular example, there are other issues where I wanted to add some additional information that I could not.

Could you please reconsider locking conversations automatically after a period of time? I understand the need to lock conversations when they go out of scope or if a debate derails from the code of conduct. But locking a closed or merged pull request after one month seems unnecessary and prevents valuable information to be potentially added later.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Often I come back to some (not that) old issues or pull requests and would like to add some additional information. Unfortunately, it has become impossible lately because @msftbot is aggressively locking conversations.

For example, in the msbuild repository, I was able to add a for the record comment more than two years after the last activity on the issue: dotnet/msbuild#539 (comment) This comment received 2 👍 so I guess it was somehow valuable.

Today I came back to an old pull request of mine (#35183) and wanted to add this additional information:

For the record: while this particular pull request has not been merged, an equivalent pull request (#51713) has been merged and has shipped as part of the .NET 6 release.

But it is impossible because the conversation is limited to collaborators. This is juste one particular example, there are other issues where I wanted to add some additional information that I could not.

Could you please reconsider locking conversations automatically after a period of time? I understand the need to lock conversations when they go out of scope or if a debate derails from the code of conduct. But locking a closed or merged pull request after one month seems unnecessary and prevents valuable information to be potentially added later.

Author:	0xced
Assignees:	-
Labels:	area-Meta, untriaged
Milestone:	-

[danmoseley]

0xced I can indeed see how it's a pain when you simply want to add a helpful note. (For what it's worth I went and added your note in this case).

Essentially the problem that locking helps with is scaling. We have nearly 60,000 closed issues and PR's and posting on these used to be fairly common. There were some comments like this where it was a helpful note for anyone that came across it (like a workaround) but in many cases it was a note that the issue wasn't actually fixed, or reporting some seemingly similar (or quite unrelated) issue, or disagreeing with the outcome of the issue or PR, continuing the conversation, or even providing more PR feedback long after the PR was merged. Much of the time these comments were never seen, which no doubt was not what the commenter wanted. In all these cases a new issue would have ensured we've seen it. So we added the locking. Now our triage workflow is organized around open issues and PR's only, which makes it easier for us to reason about, and more likely that commenters will get the outcome they want.

Which leaves helpful updates like yours. All I can suggest in these cases is to ping a maintainer elsewhere - on a similar issue, on Discord, etc - and we will be happy to add the comment.

[0xced]

Thanks for the quick reply and the explanation, Dan!

I think there's one thing that could solve this issue perfectly: enabling cross-reference on locked issues.

On non-locked issues you see someone mentioned this issue appear when an issue is mentioned in another issue:

The locked issue would stay locked but users could easily follow the additional discussion on another issue. In fact, I even hoped that this very issue would add cross-references to both #35183 and #51713 but it did not happen.

[danmoseley]

enabling cross-reference on locked issues.

Is there a setting for that? I would be happy to flip it.

[danmoseley]

I do not see such an admin setting, and it is not in the Github API: https://docs.github.com/en/rest/issues/issues#lock-an-issue

It's unfortunate that locking blocks linking as well. All I can suggest is let us know if there's one that is particularly worth adding -- or one that we should simply unlock for a while.

I assume that, as a maintainer, this forms a link in the locked issue: #35183

[danmoseley]

Ugh, it does not. I can clearly post there though.

[danmoseley]

One thing occurs to me - I believe we control the time the bot waits before locking.

[0xced]

Maybe it would be worth asking the GitHub team if they could add a setting to control whether locked issue include cross-references or not?

I believe we control the time the bot waits before locking.

Surely increasing the time to more than one month would make me happy! A few months ago I wanted to reply to @tarekgh in #63192 but I came back to this issue too late, it was already locked. 🤷

Now, what would be a good value? See, I just did it again, almost 5 years later on the .NET SDK repository: dotnet/sdk#8760 (comment) But I guess we're back to square one with such a large period. 😉