Skip to content

Add release Go/No-Go vote issue template (for async decision) #485

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
getsaurabh02 wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Add release Go/No-Go vote issue template (for async decision) #485

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d715232
Add release Go/No-Go vote issue template
getsaurabh02 Apr 1, 2026
eda5faa
Update voting rules: maintainers block, community votes reviewed by r…
getsaurabh02 Apr 1, 2026
ffd1cb9
Add Discussion section with Slack thread link and Release Manager res…
getsaurabh02 Apr 1, 2026
2907023
Add Release References section with links to release issue, notes, an…
getsaurabh02 Apr 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions .github/ISSUE_TEMPLATE/RELEASE_GO_NOGO_TEMPLATE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
---
name: 🚀 Release Go/No-Go Vote
about: Async Go/No-Go decision for OpenSearch release
Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
about: Async Go/No-Go decision for OpenSearch release
about: Async Go/No-Go decision for OpenSearch / OpenSearch-Dashboards release

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for the OpenSearch product release and not core vs dashboard

title: '[RELEASE] Go/No-Go Vote - OpenSearch <VERSION>'
Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
title: '[RELEASE] Go/No-Go Vote - OpenSearch <VERSION>'
title: '[RELEASE] Go/No-Go Vote - OpenSearch / OpenSearch-Dashboards <VERSION>'

labels: 'release'
Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
labels: 'release'
labels: ['release', 'vote']

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We dont have vote label today. Also, we can iterate on it as we learn from the releases.

assignees: ''
---

## Voting Window

**Date:** <DATE>
**Time:** 8:00 AM PST – 8:00 PM PST
Comment on lines +11 to +12
Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**Date:** <DATE>
**Time:** 8:00 AM PST – 8:00 PM PST
**Date:** <DATE> by 6PM PST

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will like to keep an extended 12 hour window atleast to overlap with all the regions.


## Release References

- **Release Issue:** [opensearch-project/opensearch-build#XXXX](https://github.com/opensearch-project/opensearch-build/issues/XXXX)
- **Release Notes Draft:** <LINK>
- **Build Status:** <LINK>

## How to Vote

- **Go:** React with 👍 on the **Go** comment below
- **No-Go:** React with 👎 on the **No-Go** comment below **and** leave a comment with your reasoning so we can follow through
Comment on lines +22 to +23
Copy link
Copy Markdown
Member

@andrross andrross Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments are probably better than reactions for this. Comments provide a audit trail that I'm not sure we'd get with reactions. If the concern raised in a -1 comment is addressed, that comment can be marked as outdated and the commenter can add a subsequent +1 comment. Reactions can be changed with little or visibility into when or why the change happened.

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One concern with using comments for everything though is with many voters, the Go comments could drown out the No-Go discussions that actually need attention.

How about a hybrid approach:

  • Go: 👍 reaction on the Go comment (low noise, easy to count)
  • No-Go: Comment with reasoning (provides the audit trail you're describing. Also attributable and can be marked outdated and followed up with a +1 comment once resolved)
  • Mandatory voters (Release Manager, Core Maintainer, Docs, Website, Blog): Always leave a comment +1 Go or -1 No-Go with reasoning.

The audit trail matters most for No-Go votes since those are the ones that need tracking and resolution. Mandatory voters always comment to ensure accountability for the votes that gate the release. Thoughts?

Copy link
Copy Markdown
Member

@andrross andrross Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually the original text is probably okay. The no-go comments are sufficient as the audit trail. As soon as the first mandatory voter leaves a +1 comment then others will pile on without reading :)

Comment on lines +22 to +23
Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Go:** React with 👍 on the **Go** comment below
- **No-Go:** React with 👎 on the **No-Go** comment below **and** leave a comment with your reasoning so we can follow through
Write / Comment `go` or `nogo` in the issue.


## Mandatory Votes

| Role | GitHub Handle | Vote |
|------|--------------|------|
| Release Manager | @ | |
| OS Core Maintainer (1+) | @ | |
| Documentation Maintainer | @ | |
| Website Maintainer | @ | |
| Release Blog Owner | @ | |
Comment on lines +30 to +33
Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| OS Core Maintainer (1+) | @ | |
| Documentation Maintainer | @ | |
| Website Maintainer | @ | |
| Release Blog Owner | @ | |
| OS Core Maintainer (1+) | https://github.com/opensearch-project/OpenSearch/blob/main/.github/CODEOWNERS | |
| OSD Core Maintainer (1+) | https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/.github/CODEOWNERS | |
| Documentation Maintainer | @ | |
| Website Maintainer | @ | |
| Release Blog Owner | @ | |

Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add OSD core owners here as well.

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OSD and all other plugins will have equal say in the vote (Go/No-Go). Only core maintainer needs to be mandatory as it is the dependency for all .


## Voting Rules

- A No-Go vote from any mandatory voter or maintainer of any `opensearch-project` repo blocks the release. No-Go votes must include an explicit comment with reasoning.
- A No-Go vote from any community member or OpenSearch user will be reviewed, with the final decision resting on the maintainer of the respective repo related to the concern.

## Discussion

For questions and discussion, use the Slack thread in #releases: <SLACK_THREAD_LINK>

> The Release Manager is responsible for surfacing any No-Go concerns raised in Slack as comments on this issue to ensure they are formally captured.

## Other Maintainers & Contributors

All maintainers and community members are encouraged to vote using 👍 (Go) or 👎 (No-Go) reactions on the respective comments below.
Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
All maintainers and community members are encouraged to vote using 👍 (Go) or 👎 (No-Go) reactions on the respective comments below.
All maintainers and community members are encouraged to vote in the issue.

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was discussed previously above: #485 (comment)
We would focus on mandatory voting and No-Go as comments for audit trail.


## Release Checklist

- [ ] All release-blocking issues resolved
Copy link
Copy Markdown

@reta reta Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If possible, would be good to include links here to release related issues (to opensearch-build repo, fe opensearch-project/opensearch-build#5966), that would help a lot to understand the status of the release (beyond the checklist), thanks!

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed, voters need easy access to the release status to make an informed decision. Adding a "Release References" section to the template with links to the opensearch-build release issue, release notes draft, and build status.

- [ ] Documentation ready
- [ ] Release blog drafted
- [ ] Website updates prepared
- [ ] CI/CD pipelines green
Comment on lines +52 to +56
Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [ ] All release-blocking issues resolved
- [ ] Documentation ready
- [ ] Release blog drafted
- [ ] Website updates prepared
- [ ] CI/CD pipelines green
* Latest RC is green on build artifact
* IntegTest/CypressTest is green
* No CVE of medium and high for over 60 days
* No performance regression
* Documentation ready
* Release blog drafted

Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Easier to insert sub-bulletin list of what is not ready

Copy link
Copy Markdown
Member

@peterzhuamazon peterzhuamazon Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove website part because that is a few clicks on WP.
Remove CI/CD pipeline becuse that is part of release blocking issues.
Add Build status
Add IntegTest
Add CVE verification
Add Performance

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can iterate on it as we learn from the releases. On website, its readiness is the key, which should have a checklist.


## Additional Context

_Add any relevant links, notes, or context for this release._
Copy link
Copy Markdown
Member

@andrross andrross Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A GitHub issue is the right place for capturing votes and any concerns related to a -1 vote.

However, they don't work well for lengthy discussions and questions. Should we create a section for a link to a slack thread in the releases channel? There's a risk of bifurcating the discussion, but slack lends itself better to questions and ephemeral discussion. What do you think?

Copy link
Copy Markdown
Member Author

@getsaurabh02 getsaurabh02 Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a fair point. The issue stays the source of truth for votes and No-Go reasoning, while Slack handles the back-and-forth discussion. To avoid bifurcation, the template can make it clear:

  • Votes and No-Go reasoning go on the issue (as a record)
  • Discussion and questions go in the Slack thread (linked in issue)
  • Any No-Go concern raised in Slack must be formalized as a comment by Release Manager on the issue to count

Copy link
Copy Markdown
Member

@krisfreedain krisfreedain Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do agree that the GitHub issue is a great way forward for this but share the concerns for keeping records of the discussion. Another option I want to throw out there is the Forum - these conversations are a LOT easier to find than Slack threads - and are a lot more legible. Slack is a quick conversation place, but if we want them long-term, consider the forum. I could even create a specific place for these if we wanted.

Copy link
Copy Markdown
Member

@andrross andrross Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but if we want them long-term

@krisfreedain The slack channel would just be for ephemeral discussion about the immediate release. It would be the responsibility of the release manager to ensure that anything that wasn't ephemeral discussion got captured in the GitHub issue.

Copy link
Copy Markdown
Member

@krisfreedain krisfreedain Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. Good to ensure that is a responsibility for the release manager. 👍

Loading