Closing issue as "not planned" instead of "completed"

[browniebroke]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched in the documentation/README.
• I already searched in Google "How to do X" and didn't find any information.
• I already read and followed all the tutorial in the docs/README and didn't find an answer.

Commit to Help

• I commit to help with one of those options 👆

Example Code

# Automatically close issues or pull requests that have a label, after a custom delay, if no one replies.
# https://github.com/tiangolo/issue-manager
name: Issue Manager

on:
  schedule:
    - cron: "12 0 * * *"
  issue_comment:
    types:
      - created
  issues:
    types:
      - labeled
  pull_request_target:
    types:
      - labeled
  workflow_dispatch:

jobs:
  issue-manager:
    runs-on: ubuntu-latest
    steps:
      - uses: tiangolo/issue-manager@0.5.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          config: >
              "wontfix": {
                "delay": 864000,
                "message": "As discussed, we won't be implementing this. Automatically closing."
              }
            }

Description

I used this GitHub action on one of the repos I maintain, and it worked great for me. Today, I used it to close an old issue, and I noticed that the issue was closed as "completed" while I was expecting it to be closed as "not planned", which sounds like a better default for this project. Is that something which is already supported?

I think that was added fairly recently to GitHub so maybe the API call made by the GitHub action needs a bit of tweaking. Perhaps it would make sense to have an option to make it configurable per label.

PS: I use this GitHub action on several of my repos, this is really helping me to stay on top of things, so thank you!

Operating System

Linux

Operating System Details

ubuntu-latest

Python Version

n/a

Additional Context

No response

[browniebroke]

Looks like this is supported in the latest version of PyGitHub by passing state_reason to the Issue.edit call (ref PyGithub/PyGithub#2392)

I guess it's a matter of changing this line:

issue-manager/app/main.py

Line 101 in 0ec1d5a

issue.edit(state="closed")

[tiangolo]

Thanks @browniebroke!

My intention with issue-manager was this:

People report things, and normally they never report back when something is handled, answered, fixed, etc. Also, in most of the cases, the issue is actually an error on their side.

In many cases, I would answer or ask for more info, but people wouldn't come back to tell me this solved their use case, or provide the extra info.

If I closed the issue right away before waiting for them to reply, I would consider it rude, because there's a chance I didn't understand what they wanted or what they were saying, or that what I said doesn't really solve their problem, or they actually come back and report the extra info.

So, the intention with issue-manager was to add a way to "close this automatically in the future if they don't come back, but if they do, keep it open".

I would want those issues to be closed as "completed" because whatever is the original request was in some way completed, they solved what they needed in some way.

---

Now, for the use case of close as "not planned", I would imagine it would be mainly for new features. And if I know that I don't plan on adding those features, I would think it would be better to say it directly, explain it, and close the issue.

I'm wondering, do you have a use case where you would want "not planned" to be closed after a while?

[browniebroke]

I see, thanks for the clear answer and detailed explanation. Yes it would probably be mainly for new features.

In cookiecutter-django we often have people suggesting adding a new library/django package/service to the template and it's not always clear wheather it's worth it: we cannot add everything under the sun. The point is to keep a right balance between things which are needed by a majority of projects vs keeping things relatively simple. In this cases I usually repond with a "maybe, if other users ask for it" and leave the request open for a little while. If there is interest, someone else will usually comment and the issue won't close. If there is no interest, I don't need to remeber about the feature request, but IMO it's not completed.

And if I know that I don't plan on adding those features, I would think it would be better to say it directly, explain it, and close the issue.

I see where you coming from, and that makes sense. I don't always feel like I'm able to answer with a "no" that quickly though, and other users/maintainers may change my mind.

This very feature I'm suggesting is perhaps an example of it: you kind of said "no" initially, but you left it open and gave me time to convince you otherwise. If I never replied, you could have left the action close an hypothetical issue as "not planned" (not sure whether dicussions can be closed like this).