WORKFLOWS: Add workflow to unassign inactive contributors

[LightCreator1007]

Task

Add a scheduled GitHub Action that warns contributors who've gone inactive on
an assigned issue, then unassigns them if they stay inactive, freeing up stale
issues for others.

The bot warns first, then unassigns 2 days later if the contributor is still inactive.

"Inactive" means the issue has been assigned for 5+ days and shows no sign of
life from the assignee. Specifically, ALL of the following are true:

• the assignee hasn't commented on the issue in the last 5 days, AND
• there's no linked PR, OR a linked PR exists but has been silent (no push or
  reply from the author since a review was left or requested).

---

Scope

In scope:

• A new workflow file (e.g. .github/workflows/stale-assignee.yml) on a schedule (daily cron).
• Detect issues with the contribution in progress label that meet the inactivity definition above.
• Warn: post a comment giving the contributor a heads-up and grace period.
• Unassign: if still inactive 2 days after the warning, remove the assignee,
  remove the contribution in progress label, and comment explaining why plus
  inviting them to re-request via /assign.

Out of scope:

• Changing the existing issue-manager.yml assignment logic.
• Touching PRs directly (we only read PR state).

---

Workflow specifications

• Trigger: schedule (e.g. cron: '0 0 * * *', once a day). Add workflow_dispatch for manual testing.
• Permissions: issues: write, pull-requests: read.
• State without a database: the warning comment doubles as the state marker.
  Include a hidden tag in it, e.g. <!-- stale-assignee-warning -->, so later runs can find it.
• Logic per assigned, labelled issue:
  1. Skip if assigned < 5 days ago. (Use the assigned timeline event for the timestamp, not created_at.)
  2. Determine activity: check for a recent comment from the assignee, AND check
     for a linked PR and its last activity. Either signal counts as active.
  3. If active and a warning comment exists from a previous run, delete it so the state resets cleanly. Then do nothing further.
  4. If inactive and no warning comment exists yet, post the warning comment with the hidden tag.
  5. If inactive and a warning comment exists and it's 2+ days old, unassign, remove the label, and post the unassign comment.
• Finding linked PRs: likely there's no direct REST endpoint for issue-to-PR links.
  Use the GraphQL API (available in github-script via github.graphql), or
  read the issue's timeline endpoint and look for cross-referenced events.
• Suggested implementation: actions/github-script@v7 (matches the style already used in this repo).

---

Notes:

• Be conservative. A wrong unassign is annoying, so when in doubt, treat as active.
• A comment from the assignee counts as activity, even if no PR exists yet. Someone
  asking for help is engaged, not stale.
• When activity resumes after a warning, delete the warning comment. This resets the
  state so the contributor gets a fresh warning cycle next time instead of being
  unassigned immediately.
• The grace periods (5 days to warn, 2 more to unassign) and cron schedule should be
  easy to find and change at the top of the script.
• "Assigned date" comes from the issue's timeline events (assigned action), since
  created_at is the issue's age, not the assignment's.
• Test with workflow_dispatch and a throwaway issue before relying on the cron.
• Linking a PR to an issue reliably needs Fixes #N / Part of #N in the PR body,
  which the repo's PR template already encourages, so lean on that.

[Harshbansal06]

Hi @LightCreator1007! I would like to help on this issue.

1. Setup: I will create the daily scheduled workflow using actions/github-script@v7. I will also add a manual button so we can easily test it on demand.
2. Checking Activity: The script will look at the issue's timeline history to see exactly when someone was assigned. Then, it will use the github GraphQL api to find any linked pull requests and see if the assignee has posted any recent comments or updates there.
3. Handling Stale Issues: If the assignee not been active for 5 days, the script will leave a warning comment containing the hidden html tag. If 2 more days pass after that warning with no updates, it will remove the user and the label.
4. Resetting: If the user becomes active again after a warning, the script will automatically delete the old warning comment to reset the cycle.

Thanks!

[Luffy-D-Zoro]

/assign

Hi @LightCreator1007 , I’d like to work on this issue.

I’ve gone through the requirements. My plan is to add a separate scheduled workflow, likely .github/workflows/stale-assignee.yml, using actions/github-script@v7.

The workflow will:

• run daily through cron and also support workflow_dispatch for testing
• check assigned issues with the contribution in progress label
• use the issue timeline to find when the contributor was assigned
• warn the assignee after 5+ days of inactivity
• use a hidden warning marker comment as state, without adding any database
• unassign the contributor 2 days after the warning if the issue is still inactive
• remove the contribution in progress label and leave an explanatory comment
• avoid changing the existing issue-manager.yml assignment logic

I’ll keep the implementation conservative so that if activity is unclear, the workflow treats the contributor as active instead of incorrectly unassigning them.

Please assign this to me.

[github-actions]

@Luffy-D-Zoro Your request has been logged! A maintainer will review the requests and assign this issue manually.

[LightCreator1007]

hello contributors, its really nice to see you active on tracking issues.
But please keep in mind to not throw around AI comments, it really does not help if you are not learning how to deal with issues.
Kindly take some time to go through the existing the workflows, plan how you would make the new one and come back.

The goal is not to get most issues as soon as they come out, but to learn. Please be honest with yourself.
Since this is a hard issue we will wait to find a good plan from your sides.

[Luffy-D-Zoro]

/assign
Hi @LightCreator1007 , sorry for the previous comment , i understand that it was not useful enough and didnt show a clear understanding of existing workflows or how i would actually implement this .
I went through the current workflow setup again and this is my current approach :

1. firstly i will create a file in the workflows(eg. stale-assignee.yml) in it i will make it run on the daily by using on.schedule,i would also add workflow_dispatch so maintainers can manually test it from the actions tab , and then create job in which i will set the permissions like [ issues : write and pull-requests: read] as specified above and uses : actions/github-script@v7 , then i will write the main logic inside the script :

2. then first i will fetch the issues by using github api (github.rest.issues.listForRepo) and will use filter for label : so that only the issues with label : contribution in progress used ,also i will use github.paginate() so that it becomes an array of issue object .and then i will filter out the pull requests using !issue.pull_request .

3.now for each issues I will fetch its timeline using github api . ,i will also use github.paginate().
4. now i will go inside the timeline reponse and then for every assigned event (which have assignees) , I will make a map which will store the (assignee, latest date ) .
5. And then i will find the assignees who are old enough to check .(which is like 5 days ) . this will prevent unnecessary comment/Pr checks .
6. Now i will fetch comments using github api ,i will also use github.paginate().
7. and now i will again make a map which will store ( assignee,their latest comment date ) .
8. I use timeline api response ,and in that i will find cross-referenced events and it will help me to find linked Pr , so i will make a set and in it i will store all the Pr numbers linked to this issue . and set will prevent duplicate number .
9. Now i will check the comments . if the assignee commented in the last 5 days - i will check if there is a warning comment and remove it ,if not continue . but if there is no comment in last five days . i will push the assignee name in a array , which i will use to check the PR next for activity check
10. Now i will fetch the Pr's by github.rest.pulls.get();,here i will use my prNumber set which i made in step 8 for filtering and then i will make a set activePrassignee which will store the assigne which have done some activity before deadline .
11. now by using my last two sets which i made in 9 and 10 i will check the activity and if the user is active i will remove the warning comment if present ,if no recent comment and no pr activity - i will mark it inactive , and if Pr unclear - then i will take it as active .
12. So now if inactive and no warning exist i will post warning using Github api github.rest.issues.createComment()
13. but if warning already exist , i will check if it is two days old or not , if not i will wait . If it is 2 days + ,then i will unassign the assignee. and then update the label contribution-in-progress if there is no assigne remaining .
14. also I will Post a comment After unasssign for explaination to the assignee

I know this issue is harder than a normal workflow change, so I may still be missing edge cases. I have gone through the existing workflow and tried to break the problem into a concrete implementation plan, but I am open to feedback if this approach needs changes before implementation.

If this direction looks reasonable,I would like to work on it.

[github-actions]

@Luffy-D-Zoro Your request has been logged! A maintainer will review the requests and assign this issue manually.

[kalikant2008-netizen]

/assign
Hi @LightCreator1007 .

I'd like to take this on. When I thought about this issue ,it looks hard because it involves more than just a few steps which have to be implemented properly.
The main difficulty is accurately tracking the timeline events and PR cross-reference via GraphQL.So While implementing i will create a YAML file using actions/github-script@v7 and include a workflow_dispatch trigger so we can safely test everything first.After that the main task is to use if/else statements on managing the state properly by taking care of scopes as they can create a mess if not taken care of .
I'll use JavaScript to look for and inject the hidden comment tag. This will let the daily script easily track whether an issue is in the 5-day inactivity window or the 2-day grace period

Please assign this to me .

[github-actions]

@kalikant2008-netizen Your request has been logged! A maintainer will review the requests and assign this issue manually.

[prashant273000]

/assign

Hey @LightCreator1007, I also want to work on this issue. My plan is:

1. To create .github/workflows/stale-assignee.yml with a daily cron schedule and workflow_dispatch so we can test it manually also.
2. Set permissions to issues: write and pull-requests: read, and use actions/github-script@v7 BECAUSE we need to make multiple github api calls and the github script gives us built in github object to do such thing.
3. Fetch all issues with the "contribution in progress" label using github.paginate() and filter out pull requests.
4. For each issue, fetch the timeline events and find the assigned event to get the real assignment date — not created_at, becuase that is the date when issue was opened, not when someone was assigned.
5. Skip the issue if it was assigned less than 5 days ago.
6. Check if the assignee has commented in the last 5 days. If yes - treat them as active.
7. For linked PRs, scan the timeline for cross-referenced events to get PR numbers, then check those PRs for recent activity from the assignee. If anything looks unclear, treat as active to be safe.
8. If the assignee is active and a warning comment exists from a previous run, delete it so the cycle resets cleanly.
9. If inactive and no warning exists yet, post a warning comment with a hidden tag so future runs can detect it.
10. If inactive and the warning comment is already 2+ days old, unassign the contributor also remove the label, and leave a comment explaining that he was inactive and this issue has been unassigned to him.

Hoping that this issue gets assigned to me.

[github-actions]

@prashant273000 Your request has been logged! A maintainer will review the requests and assign this issue manually.

[LightCreator1007]

@Luffy-D-Zoro I have a few questions:

1. For a linked PR, what exactly will you read to decide it's active?
2. How will you handle the "silent since a review was requested" rule?
3. How do you find the warning comment on a later run?
4. When you say "linked PR," does a PR that just mentions the issue count, or one that says Fixes #N / Part of #N?
5. What happens if an issue has two assignees and only one is inactive?
6. Will the grace periods and cron live as named constants at the top of the script?

[DjYash007]

/assign
Hello @LightCreator1007 , I have gone through the the given workflow spec, important notes and given possible solutions.

I think this workflow has many different subsystems of which most of them are covered in above comments. But, I would like to refine one of the subsystems of the workflow. We have a subsystem to handle the not PR link part. I propose this solution for the PR links specifically.
The subsystem I could work on is GraphQL PR Activity Check. (For PR link only)
How it fits in the flow:
The spec says lean on Fixes #N / Part of #N in the PR body. So we don't scan timelines for cross-referenced events. Instead:
Fetch open PRs in the repo
For each PR, check its body for the pattern Fixes #<issue_number> or Part of #<issue_number>
That gives you the PR number linked to the issue

This is simpler than GraphQL timeline scanning.

Next steps after identifying the PR status
The decision making strat:
Step 1 - author check:
if PR author is not assignee login I would ignore this PR entirely
Someone else opened a PR referencing the issue. Doesn't count as assignee's activity.

Step 2 - no reviews ever existed:
if no reviews along with no review requests:
check assignee's last commit date
within 5 days then active
older than 5 days inactive

PR is freshly opened, no reviewer has looked at it yet. Commit recency is the only signal.

Step 3 - review exists or was requested:
latest_review = most recent timestamp among:

• all review createdAt dates
• all review request createdAt dates

then the script checks:
did assignee commit AFTER latest_review_ts? if yes active
did assignee comment AFTER latest_review_ts? if yes active
neither → inactive

Step 4 - conservative fallback:
if anything is ambiguous or data is missing active

On the decision
Three possible results will be fed back into the main flow:

ACTIVE — assignee is working, do nothing
INACTIVE — no response after review, proceed with warning logic
SKIP — PR is already merged, work is done, exit this issue entirely

That's it! This what I'd do for this problem! This is the approach

IMPLEMENTATION
step 1: find PR number via Fixes #N body parsing
step 2 single GraphQL query will give reviews + commits
step 3 : will check assignee response after latest review timestamp