-
Notifications
You must be signed in to change notification settings - Fork 6
Description
Observed behavior
.github/workflows/contributor-issue-comment.yml workflow that handle contributors comments on GitHub issues doesn't work as expected when
- A close contributor (defined in this list), who is also a member of one of Learning Equality teams (such as GSoC Contributors), comments on non-"help-wanted" issue
- Then no Slack notification is sent to
#support-devSlack channel
Expected behavior
- A Slack notification needs to be sent to
#support-devSlack channel for a close contributor, and no matter on what issue they comment on (both "help-wanted" and non-"help-wanted")
Steps to reproduce
I observed this when Habiba (who is on the list of close contributors as "habibayman") posted this comment. Related workflow run:
Comments
I haven't confirmed in code, but I believe this is most likely caused because for any Learning Equality GitHub team members, github.event.comment.author_association will be MEMBER and so due to this condition the script that handles close contributors won't even get called.
Guidance
This would ideally be solved by
- Adjusting the workflow to not be skipped if a contributors is a member of these teams
Furthermore, it'd be best if contributors from these two teams would automatically be considered as close contributors without the need to add them to the constants list manually.
Therefore, the final close contributors group would be merging of these three sources: Constants list + GSoC Contributors GitHub Team + Learning Equality Community Guide GitHub Team. In the example above, this would mean that we would (1) receive #support-dev notification for Habiba's comment, (2) with additional benefit of this approach that it would still work even after we'd remove her handle from the constants list.
Finally, since there are other workflows that suffer from the same issue, it would be ideal to have the final output of this evaluation implemented in as re-usable way as possible. E.g. it could be a separate re-usable yml job that would call a JavaScript utility function that would contain the conditions. In this way we could easily import this evaluation as both (1) a JavaScript isCloseContributor(<handle>) function in JS scripts and (2) condition/job is-close-contributor.yml to be used from .yml jobs (we have use-cases for both in the codebase). is-close-contributor.yml would ideally too call isCloseContributor JavaScript so that we have a single source of truth for evaluation close contributor group membership.