Enhance Slack notifications and automate GitHub assignment replies based on issue labels

[GarvitSinghal47]

🙂 Looking for an issue? Welcome! This issue is open for contribution. If this is the first time you’re requesting an issue, please:

• Read the Contributing guidelines carefully. Pay extra attention to the Using generative AI. Pull requests and comments that don’t follow the guidelines won’t be answered.
• Confirm that you’ve read the guidelines in your comment.

Enhanced Community-related Slack Notifications and GitHub Automated Replies System

Background

Our current process uses the notify_team_new_comment action to post notifications of every external comment to the #support-dev Slack channel. While this keeps the core team informed, the high volume of notifications—especially for duplicate requests or non-assignment comments—leads to information overload.

Summary

To enable the core team to focus on the most important issues, the current system should be updated as follows:

1. Issue Label Differentiation

   • Help-Wanted Issues
     • Continue current behavior (sending notifications to the #support-dev Slack channel and no automated reply on GitHub).
   • Non “Help-Wanted” Issues

     • Automatically post a GitHub reply (via the Learning Equality bot) if the contributor’s comment includes assignment-related keywords (e.g., “assign”, “assign me”, “please assign”, “claim”).

     • Trigger on every external comment; the action will then locate the last bot comment in that issue and only post a new reply if at least an hour has passed since the last one, keeping things efficient without complex polling.

     • The automated reply will inform the contributor that the issue is not available for assignment and include links to our contributing guidelines.

       Example:

       Hi @<username> 👋
       
       Thanks so much for your interest! This issue is currently reserved for the core team and isn’t available for assignment right now.
       
       If you’d like to get started contributing, please take a look at our [Contributing Guidelines](https://github.com/your-org/your-repo/blob/main/CONTRIBUTING.md) for tips on finding “help-wanted” issues, setting up your environment, and submitting a PR.
       
       We really appreciate your willingness to help—feel free to pick another issue labeled **help-wanted** and let us know if you have any questions. 😊

     • Regardless of whether the automated reply is posted, all qualifying comments (except those on pull requests and from maintainers, known bots, or contributors on the exclusion list) will trigger a Slack notification to the #support-dev-notifications channel.

2. Slack Notifications

   • For Help-Wanted Issues
     • Send notifications to the #support-dev Slack channel using the SLACK_WEBHOOK_URL.
   • For Non “Help-Wanted” Issues
     • Send notifications to the #support-dev-notifications channel using the SLACK_COMMUNITY_NOTIFICATIONS_WEBHOOK_URL.
   • Every notification will include the repository name, a link to the comment (with the issue title properly escaped), the contributor’s username, and a direct link to the LE bot’s comment.

3. Close Contributors List

   • There is a list of GitHub handles. For contributors on this list, we never post an automated GitHub reply and notifications are always sent to #support-dev (regardless of whether they comment on help-wanted or non–help-wanted issues).
   • The list will typically contain a small number of very close contributors. In the first version, the list will be maintained manually.

Implementation Details

• Trigger:
  The workflow is triggered by the issue_comment event.

• Logic Flow:

• Secrets and Webhooks:
  • Use SLACK_WEBHOOK_URL for notifications to #support-dev (help-wanted issues).
  • Use SLACK_COMMUNITY_NOTIFICATIONS_WEBHOOK_URL for notifications to #support-dev-notifications (non–help-wanted issues).

Acceptance Criteria

• Follows the specification above
• Implementation is manually tested
• If logic from other actions is reused, it is refactored into helper methods (no new duplicates)
• No regressions in any of the affected actions
• Implemented in JavaScript

References

• Current notify_team_new_comment Workflow

[GarvitSinghal47]

keywords.txt

Created a list of 100 words to trigger the bot using chatgpt can use this as a starting point and can change in it furthur

assign, assign me, please assign, assign to me, assign this, claim, claim this, i claim this, i’ll take this, take this, taking this, taken, i want this, mine, dibs, this is mine, i’ll do this, i’ll take care, let me take this, can i take this, can i work on this, can i help, can help, let me help, i want to help, want to help, working on this, i’m on it, i’ll work on it, i want to work, want this, i can do this, can do this, i can solve this, can solve this, let me try, i’ll try, i’ll try this, trying this, i’ll pick this, pick this, picking this, want to pick, grab this, grabbing this, i’m interested, interested, i want in, count me in, i’m doing this, doing now, will do, i’ll handle this, let me handle, let me solve, solve this, want to solve, taking charge, let me take care, taking it, bagging this, need this, can i own this, i’ll own this, i want to own, let me own this, i own this, assign it, this one please, working on it, i’ll do it, let me do it, doing it, i’ve got this, got this, i got this, my task, my issue, my pick, take charge, assign pls, assign me pls, let me pick, can i take, can i pick, can i try, need assign, i’m available, available to help, want issue, need issue, pick for me, pick me, assign me this, ready to help, mark mine, flag mine, dibs on this

[MisRob]

Perfect, thanks for putting this together @GarvitSinghal47

[MisRob]

Since this will update existing shared actions, I'm adding our general guidance on how to organize work:

General guidance for developing shared GitHub actions

Shared actions are placed in the .github repository, with most logic centralized there. Follow these steps for smooth development and review:

(1) Develop locally in your own environment

Start by setting up your own testing environment:

• Create your own .github repository
• Create another repository to test importing and running the shared .github action

Depending on the action, you may also need:

• A GitHub organization
• Slack app
• Spreadsheets app
• Other integrations as needed

Before proceeding to next step, make sure action works well in your environment.

(2) Open two pull requests: .github and test-actions

Once everything works locally, open two pull requests to the Learning Equality repos:

1. Reusable shared logic to the .github repository
2. A small action that calls (1) to test-actions repository

Think of test-actions as a stand-in for the production repos listed below.

During this step, we'll review and test your action in our environment and coordinate with you as needed.

(3) Enable the shared action in production repos

After our approval, you can roll out the action by opening pull requests to production repositories, typically:

A. kolibri
B. kolibri-design-system
C. studio
D. ricecooker
E. le-utils

Each pull request should include the same tested code from test-actions that calls the shared action from .github.

Programming language

Use JavaScript for actions that need more than a few lines.

Third-party workflows

For security and maintainability, we prefer our own implementations, optionally combined with official third-party workflows when needed.

Example

• Shared action and its script in .github repository
• Calling the action from kolibri repository

More examples are available in .github and kolibri, studio,... repositories referenced above.

[iamshobhraj]

Hi @MisRob @GarvitSinghal47 can I help with this?

[MisRob]

Yes, that'd be great @iamshobhraj. Assigned!

[MisRob]

Closed by #29

[MisRob]

Very nice work @iamshobhraj and @GarvitSinghal47, thanks both! I am going to turn it on now in all main repositories.