Adding actions to automate auto issue assignment and reminder on inactivity

[rgsl888prabhu]

Description

Adding actions to automate auto issue assignment and reminder on inactivity.

Issues

• Issue with "awaiting response" label are the only ones which will be tracked/notified
• If this is removed, then this will not be tracked
• Another option is also to use label "skip inactivity reminder"

PR

• All the PR will get notified which are open
• If it is a draft PR, it will not be notified
• Same label can be used here if you want to disable the notifier

This way we not get pinged for all back-logged issues and only pings any important and recent ones which we deemed good.

example issue - #309 (comment)
example PR - #310 (comment)

If there is no asignee, by default it will ping @anandhkb on all issues and PRs

Issue

closes #255

Checklist

• I am familiar with the Contributing Guidelines.
• Testing
  • New or existing tests cover these changes
  • Added tests
  • Created an issue to follow-up
  • NA
• Documentation
  • The documentation is up to date with these changes
  • Added new documentation
  • NA

[tmckayus]

This looks good to me, as long as we remember that assignee in this setup is the PIC and not necessarily the one doing the implementation.

[rgsl888prabhu]

This looks good to me, as long as we remember that assignee in this setup is the PIC and not necessarily the one doing the implementation.

Agree, this is just to notify one of us so we can ping an appropriate group for more help.

[rgsl888prabhu]

@jameslamb may I get your review on this PR

[jameslamb]

If it were up to me, I would not introduce this round_robin_assign bot at all, and I would make the inactivity_reminder bot much less verbose.

I put some specific ideas about that in comments on this PR, and added some other ideas in #255 (comment) on how you could solve the project management problems you're facing without new bots.

One other minor point here... these new workflows will eat into this repo's GitHub API rate limits. That will increase the risk of builds failing because they cannot upload / download artifacts, for example. I don't think it will be too much of a worry at this repo's current activity levels, but another argument in favor of trimming this down.

If you experience problems like that, please note that the RAPIDS CI workflows you're using have a "Check GitHub API Rate Limits" step that you can use to see your usage:

https://github.com/NVIDIA/cuopt/actions/runs/16983366956/job/48147813721#step:11:28

---

Despite my concerns about this, I'm going to mark this "Approve". You all can handle prioritization, project management, and communication with your users/contributors in whatever way you decide. The implementation looks ok to me and I don't think it'd affect security, performance, correctness, etc. here.

But please do consider some of my suggestions.

[jameslamb]

I think it'd be helpful to add workflow_dispatch: for these workflows, so you can test changes by manually triggering them from the GitHub UI.

That'd only work if you opened the PR from a cuopt branch (not your fork), though.

[rgsl888prabhu]

Yeah, let me test this out.

[rgsl888prabhu]

@jameslamb tested it and behavior is noted in the description #268 (comment)

[rgsl888prabhu]

/merge