dessant/lock-threads

Support for answered (but not closed) discussions?

JustArchi opened this issue · 2 comments

Hey!

I've given a try for discussions locking as introduced in #25 but from what I see, the action currently only closes discussions in state of is:closed is:unlocked, as stated in the search query in the source code.

Now, this makes total sense for issues and PRs, since those can be either open or closed, and it makes sense to only touch those that are closed. With discussions however, we can have answered discussions that are not closed. Of course we could instead answer and close the discussion, but very often even after marking something as answered, it's expected that there can be some related activity before the discussions entered into semi-closed "stale" state which is answered but not closed just yet.

Would it make sense to extend the functionality for discussions and make a query of something like (is: closed || is:answered) is:unlocked instead? What I mean is, it'd be welcome addition to close the discussion (in addition to locking it) if it's answered but not closed yet, after given inactivity.

I imagine this as two new options added, in particular:

discussion-process-answered: true # whether to process answered discussions in addition to closed
discussion-close-answered: true # whether to close in addition to locking answered discussions, requires discussion-process-answered

This way people would have two additional use cases of also locking answered discussions, and optionally also closing them before locking.

Another question is whether we shouldn't have a property that processes all not locked discussions instead. Since discussions, unlike issues, do not usually carry "work to be done", they just get stale after some time, so in perfect world I'd like from action to close and lock everything that didn't get update in e.g. 90 days, regardless of whether it's open, answered or closed. So maybe instead of above, it'd make more sense for:

discussion-process-statuses: [ 'open', 'closed', 'answered' ] # which statuses to process, defaults to closed
discussion-close-on-lock: true # whether to close the discussion in addition to locking, defaults to false

Thanks in advance for considering it!

Of course, it makes perfect sense! This would have been the default behavior if GitHub would not have implemented closing discussions, but we could still add it as an optional feature.

Another question is whether we shouldn't have a property that processes all not locked discussions instead.

Lock Threads will only act on discussions that are closed or answered. Closing open and unresolved threads is a feature provided by actions/stale. Though users generally dislike that action because maintainers often do not use it correctly and close/lock unfixed issues that have been previously triaged, and I guess the same will be true when they add support for discussions and cut people off from posting in unresolved threads.