[FEATURE] Mechanism to link the GitHub user alias to public slack username.

[prudhvigodithi]

Is your feature request related to a problem?

Coming from central release dashboard vision #51, Implementing a mechanism to link GitHub user aliases to public Slack usernames would greatly enhance communication in the public Slack release channel during releases. This would simplify tagging release owners for plugins when issues arise with build and integration tests, and enhance closer collaboration on release-related tasks within Slack.

This will also allow the team to create automations to push a message in slack using the slack username or comment on the GitHub release issue tagging with GitHub alias for pending action items (example like missing release notes tag the plugin level release owner to add the release notes).

What solution would you like?

• In the metrics cluster filter the release issues that has the release owner assigned (Example for 2.17.0, the dashboard link with release owners assigned).

• In the metrics cluster filter the release issues that has does not have the release owner assigned. (Example for 2.17.0 issues with no release owner, dashboard link)

• Have a slack mapping for the GitHub user alias to slack username, example as follows
  { name: Prudhvi Godithi, company: Amazon, slack_username: prudhvi godithi, github_alias: prudhvigodithi }
  The above data will be collected and improved over the course of the releases. We can collect and start with the known data and use that data for the upcoming release, as we have the larger dataset and over the period of time we can directly invoke the automation to tag in github using github_alias and in public slack using slack_username.

• Visualization to link OpenSearch public slack username with GitHub alias: Visualization to link GitHub owner alias which can be used by the release manager #59. Having this Visualization a data table will be the entry criteria for the release, any repos without the release owners (with no assignees to the release issue) will be flagged and does not qualify to be part of the release candidate. A release manager will use this visualization during the release and will tag the repo maintainers to address this soon to avoid the release delays (this can be automated as well, periodically comment on the release issue tagging the maintainers to assign the release owner).

Do you have any additional context?

Here are some examples of problems (from past releases) when there isn't a designated release owner.

• For the 2.12.0 release, fixing spotlessJava to unblock [AUTOCUT] Distribution Build Failed for performance-analyzer-2.12.0 performance-analyzer#611, related PR [Release 2.12.0] fix spotlessJava performance-analyzer-rca#539 which was created by the release manager as there is no owner assigned. One more PR created by @reta Update spotless to meet JDK-21 baseline performance-analyzer-rca#533 in the same situation. Eventually these PR's are approved and merged by the maintainers, but having a release owner would have ended by avoiding the delays.

• For the release 2.16.0 there was a delay by a day [RELEASE] Release version 2.16.0 opensearch-build#4771 (comment), this is due to the last minute owner assignment for the alerting plugin, ultimately thanks to folks who fixed the alerting integration test issues, but with proper owner assignment this would have taken care 2 weeks before the release and would not caused the delays.

• The release notes are not added until the last minute, tagging the owners makes it easier to notify them and communicate reminders in the public Slack release channel.

• Delay in merging the version increment PR's, communicating/tagging the pending PR's directly to the assigned repo specific release owner would be easier and improves the process.

• Today even though the release branch creation is automated, after the release branch is created, the maintainers will go back to the branch add/removes the commits. The branch creation can be handled by the assigned repo release owner.

• Having a release owner for a the repo will improve the repo issue, labels, PR's management.

[prudhvigodithi]

Adding @getsaurabh02 @peterzhuamazon @dblock @reta for more pointers and thoughts on this issue.
Thanks

[peterzhuamazon]

I wonder if we can create a direct mapping as part of the slack to display their github name, or display slack name on github, instead of showing a table in metrics board.

But this is definitely a good start.

Thanks.

[prudhvigodithi]

Ya Peter, we can even maintain a file (or index it to the metrics cluster) with all the mappings of GitHub and slack and use it during the release, the table in metrics board is just to flag the repos with no user (owner) assigned to the release issue. Once the user is the assigned, by using the mapping pull the slack username and start the communication from there, since we already have the GitHub user alias (assigned to the release issue) we can tag in GitHub easily.

My Idea is the GitHub user alias is the source of truth (the one assigned to the repo release issue). Today we have slack to communicate easily but tomorrow we might have some other tool. So the primary key here is the GitHub user alias and based on the alias using the mapping pull the slack or any other username for chat level communication.

[dblock]

Maybe we can have json profiles that users fill out in https://github.com/opensearch-project/community? A dblock.json could get created by a bot the first time I contribute to the project in any way and I could get a @ to fill it out.

I can see other uses of community profiles, such as authors for the blog posts, etc.

[prudhvigodithi]

We have this contributors data in metrics cluster (Using the contributors API) and we can create json profiles from the data, moving forward it would be easy if a new document is created add a json profile. Once the profile is added we can keep updating the profile (manually by raising the PR) with slack_username, company and other information as required periodically with what ever information we have.

Once the release owner is assigned to the component release issue, use these json profiles to communicate in slack or other mediums. I have created a PR opensearch-project/opensearch-build#4950 to mandate the component level release owner assignment. @dblock @getsaurabh02 @peterzhuamazon WDYT?

[reta]

I am wondering if this is a desired feature at all, or at least it should be strictly opt-in may be, due to the amount of the Github notifications, adding more channels would not help but overwhelm I think.

[prudhvigodithi]

I am wondering if this is a desired feature at all, or at least it should be strictly opt-in may be, due to the amount of the Github notifications, adding more channels would not help but overwhelm I think.

Hey @reta coming from our 2.16.0 retro items to have an component specific release owner, the tagging and notifications will be only for the component specific release owner (during the release cycle). Having this mechanism during the release a release manager will be able to tag the specific owner in GitHub and will be able to communicate in slack for the release action items. While we already have a release slack channel for communication, the absence of a dedicated release owner for each component sometimes causes delays in completing action items. To address this, we use this mapping system to tag the appropriate individuals on GitHub and slack.

Thank you

[reta]

Hey @reta coming from our 2.16.0 retro items to have an component specific release owner, the tagging and notifications will be only for the component specific release owner (during the release cycle)

Thanks @prudhvigodithi , yes, that makes perfect sense, BUT: would the communication happen over Slack only or Slack + Github (release issue(s), prs, etc.)? In other words, what would not be communicated over Github but Slack?

[prudhvigodithi]

Thanks @reta, currently we are doing Slack + Github. The Github reflects the current status of the release and will be the source of truth, slack acts as a secondary communication and fallback when there are pending action to taken care of from the components. Ideally the entire release has to be driven from Github, until we get there we should leverage slack to tag/poke the owners to complete the release action items.
Thank you

[reta]

Thanks @reta, currently we are doing Slack + Github.

Thanks @prudhvigodithi , so may be this is the way to roll it out: we could ask people to share their Slack contact if they are not against being poked over it, but not require it. Sounds like a tradeoff?

[prudhvigodithi]

True @reta true there should be an opt in way if folks are not interested in slack tags, but for 2.17.0 we can start by having a release owner assigned in GitHub (PR to make this as an entry criteria opensearch-project/opensearch-build#4950) and start by tagging in GitHub for pending plugin action items and see how it goes.
Thanks
@getsaurabh02 @gaiksaya

[dblock]

Note that we have https://github.com/opensearch-project/project-website/tree/6d5b993daacb8b6f7f8936fd99af79bf71e84375/_community_members today to which Slack information could be added. I think that entire folder should be refactored into maybe https://github.com/opensearch-project/community?

[krisfreedain]

The _community_members folder from the project website repo is what populates the pages here https://opensearch.org/community/members
Example page: https://opensearch.org/community/members/kris-freedain.html
These pages currently are created when either a person writes a blog post, or, speaks at an OpenSearchCon.
One example would be to have each person create their own page, and we can enhance the page with a place for them to add a link to their Slack profile.
This would definitely take a long time.

Another, would be to house a list of maintainers/committers and their Slack/GitHub links in the Community repo as dB mentions.

[krisfreedain]

A simple, first step could also be to add a field to each repositories "MAINTAINERS' file so we can identify them in Slack as well. Example:

Current Maintainers

Maintainer	GitHub ID	OpenSearch Slack ID	Affiliation
Kris Freedain	krisfreedain	Kris Freedain	Amazon

[prudhvigodithi]

Thanks @dblock and @krisfreedain.

Today for the Release Metrics Dashboard there are mechanisms added to make sure the release owners (the component level release issue assignees) are pulled and displayed, flagging the repos with no release owners.

Coming to the topic related to have generic user profiles which can have more fields like OpenSearch Slack ID etc (where metrics project can re-use them for any desired automation).

• Adding to the maintainers file is a good idea, but as we go I can imagine we might need more fields similar to OpenSearch Slack ID plus this maintainers file limits to the profiles of only the repo maintainers and will not have data of other contributor profiles.

• (Recommend) We can have a user profile in https://github.com/opensearch-project/community as follows and we can keep expanding with more fields. For this we might need to use this existing github contributors data to create the user profiles. However, adding the OpenSearch Slack ID to each contributor's profile is something we need to look, as not every contributor may be part of the OpenSearch Public Slack. Additionally, a contributor's GitHub alias may differ from their Public Slack ID.

{
Name:  Prudhvi Godithi,
GitHub Alias: prudhvigodithi,
OpenSearch Slack ID: prudhvi godithi,
Company: Amazon
}

• We can re-use the https://github.com/opensearch-project/project-website/blob/main/_community_members/ to add one extra field OpenSearch Slack ID and later refactor to move to https://github.com/opensearch-project/community as user profiles, the refactoring should happen for the project-website code to look up profiles in https://github.com/opensearch-project/community repo. Adding a slack ID field and re-using the project-website `_community_members/ data for now might not have all the contributors, release participants information.