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

Support for answered (but not closed) discussions? #45

Open
JustArchi opened this issue Nov 14, 2023 · 2 comments
Open

Support for answered (but not closed) discussions? #45

JustArchi opened this issue Nov 14, 2023 · 2 comments

Comments

@JustArchi
Copy link

JustArchi commented Nov 14, 2023

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!

@dessant
Copy link
Owner

dessant commented Nov 19, 2023

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.

@dessant
Copy link
Owner

dessant commented Nov 19, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants