search

dessant / lock-threads

GitHub Action that locks closed issues, pull requests and discussions after a period of inactivity
https://github.com/marketplace/actions/lock-threads
MIT License
313 stars 34 forks source link

What is the purpose of locking old issues? #13

Closed RichardBradley closed 5 years ago

RichardBradley commented 5 years ago

Please could you add a note to your readme explaining the purpose of this bot?

I regularly encounter issues on GitHub which have been incorrectly or partially fixed and I find I am unable to comment on them because they are "locked" by this bot. I then need to raise a new issue, which wastes everyone's time, rather than being able to continue an existing conversation.

I can't understand why anyone would want this behaviour, and your current documentation does not address the purpose of the bot. What issue does it solve? When should a project use it? When should they not use it?

Many thanks,

Rich

dessant commented 5 years ago

Maintainers use the app because they do not want closed and inactive issues to be revived, but to receive new issues with fresh and relevant details. Filtering out the useful information from old threads is a real drag for teams once the project becomes moderately popular, and I have the same error type of comments are rather popular on closed issues, most of them ultimately turning up being user errors, or being irrelevant to that thread.

Once you find a bug, It's best to follow the workflow of maintainers and open a new issue with details, and relevant links to past issues or pull requests, if any.

I'll add a description to the README at some point, but this should be usually laid out in the contribution guide of the respective project, or in a comment made before locking.

hzoo commented 5 years ago

FYI I wrote a blog post about this https://www.henryzoo.com/an-issue-with-issues/

RichardBradley commented 5 years ago

Your blog post is interesting; thanks for posting it here.

I find it extraordinarily ironic that you would continue this discussion on an issue that has been closed for 8 months, yet your post appears to argue in favour of the odious "lock threads" that would have forbidden your constructive comment outright if it were turned on here.

All the arguments in favour of "lock threads" (and similar bots) appear to follow the same pattern as yours and are based on "eternal September" type arguments -- you presume that anyone commenting on an old issue is wrong and that "the issue is actually unrelated". You completely disregard the case where the issue is still live and merits further discussion, but has been closed anyway (e.g. with a partial fix or simply for "Inactivity").

I understand that many open source projects are plagued by low quality or misguided comments, but in my opinion, arbitrarily locking threads for "inactivity" or "staleness" causes a great deal of collateral damage. (Insidiously, that damage is often completely invisible as contributors are just driven away.) There must be a better way.

hzoo commented 5 years ago

find it extraordinarily ironic that you would continue this discussion on an issue that has been closed for 8 months

Agreed, decided to post it anyway! I guess we figure that it would be fine to just make a new issue and link to the old one if it is related? I think it's up to the project on how they want to be able to filter out things (we don't use the stale bot but are using the lock bot) - it's a tradeoff we are making at the moment - other ways to contribute via our chat/another issue. I did suggest another interface to GitHub that they could help you submit a new issue with the last comment which I think could be helpful. (I think you brought up some good points either way)

dessant commented 5 years ago

The app only locks closed issues which are inactive, and it can be configured to ignore issues with certain labels. When used the right way, it is a valuable moderation tool that helps with keeping large projects (and the mental health of maintainers :yum: ) in check, and I believe that comes before the convenience we lose as users to be able to post whenever and wherever we want, and force maintainers to deal with it, hundreds of times a day.