Add release Go/No-Go vote issue template (for async decision)#485
Add release Go/No-Go vote issue template (for async decision)#485getsaurabh02 wants to merge 4 commits intoopensearch-project:mainfrom
Conversation
getsaurabh02
changed the title
getsaurabh02
changed the title
Signed-off-by: Saurabh Singh <sisurab@amazon.com>
getsaurabh02
force-pushed
the
add-release-go-nogo-template
branch
from
fad2f5c to
d715232
Compare
getsaurabh02
requested review from
CEHENKLE,
mch2 and
saratvemulapalli
as code owners
…epo maintainer Signed-off-by: Saurabh Singh <sisurab@amazon.com>
|
Adding @Pallavi-AWS @andrross @peterzhuamazon @mch2 @reta @krisfreedain @jhmcintyre @kolchfa-aws for additional feedback . |
|
I definitely like making this process async and more inclusive |
|
|
||
| ## Additional Context | ||
|
|
||
| _Add any relevant links, notes, or context for this release._ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Makes sense. Good to ensure that is a responsibility for the release manager. 👍
…ponsibility Signed-off-by: Saurabh Singh <sisurab@amazon.com>
| - **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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :)
|
|
||
| ## Release Checklist | ||
|
|
||
| - [ ] All release-blocking issues resolved |
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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.
…d build status Signed-off-by: Saurabh Singh <sisurab@amazon.com>
| @@ -0,0 +1,60 @@ | |||
| --- | |||
| name: 🚀 Release Go/No-Go Vote | |||
| about: Async Go/No-Go decision for OpenSearch release | |||
There was a problem hiding this comment.
| about: Async Go/No-Go decision for OpenSearch release | |
| about: Async Go/No-Go decision for OpenSearch / OpenSearch-Dashboards release |
There was a problem hiding this comment.
This is for the OpenSearch product release and not core vs dashboard
| --- | ||
| name: 🚀 Release Go/No-Go Vote | ||
| about: Async Go/No-Go decision for OpenSearch release | ||
| title: '[RELEASE] Go/No-Go Vote - OpenSearch <VERSION>' |
There was a problem hiding this comment.
| title: '[RELEASE] Go/No-Go Vote - OpenSearch <VERSION>' | |
| title: '[RELEASE] Go/No-Go Vote - OpenSearch / OpenSearch-Dashboards <VERSION>' |
| name: 🚀 Release Go/No-Go Vote | ||
| about: Async Go/No-Go decision for OpenSearch release | ||
| title: '[RELEASE] Go/No-Go Vote - OpenSearch <VERSION>' | ||
| labels: 'release' |
There was a problem hiding this comment.
| labels: 'release' | |
| labels: ['release', 'vote'] |
There was a problem hiding this comment.
We dont have vote label today. Also, we can iterate on it as we learn from the releases.
| **Date:** <DATE> | ||
| **Time:** 8:00 AM PST – 8:00 PM PST |
There was a problem hiding this comment.
| **Date:** <DATE> | |
| **Time:** 8:00 AM PST – 8:00 PM PST | |
| **Date:** <DATE> by 6PM PST |
There was a problem hiding this comment.
I will like to keep an extended 12 hour window atleast to overlap with all the regions.
| | OS Core Maintainer (1+) | @ | | | ||
| | Documentation Maintainer | @ | | | ||
| | Website Maintainer | @ | | | ||
| | Release Blog Owner | @ | | |
There was a problem hiding this comment.
| | 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 | @ | | |
There was a problem hiding this comment.
Add OSD core owners here as well.
There was a problem hiding this comment.
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 .
| - [ ] All release-blocking issues resolved | ||
| - [ ] Documentation ready | ||
| - [ ] Release blog drafted | ||
| - [ ] Website updates prepared | ||
| - [ ] CI/CD pipelines green |
There was a problem hiding this comment.
| - [ ] 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 |
There was a problem hiding this comment.
Easier to insert sub-bulletin list of what is not ready
There was a problem hiding this comment.
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
There was a problem hiding this comment.
We can iterate on it as we learn from the releases. On website, its readiness is the key, which should have a checklist.
peterzhuamazon
left a comment
peterzhuamazon
left a comment
There was a problem hiding this comment.
I also suggest to ask people to vote in comments.
Because emoji can be easily removed and added without traces.
Thanks.
|
|
||
| ## Other Maintainers & Contributors | ||
|
|
||
| All maintainers and community members are encouraged to vote using 👍 (Go) or 👎 (No-Go) reactions on the respective comments below. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
This was discussed previously above: #485 (comment)
We would focus on mandatory voting and No-Go as comments for audit trail.
| - **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 |
There was a problem hiding this comment.
| - **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. |
5 participants
Today the release manager conducts a synchronous call to gather Go/No-Go votes. Given the growth of the project and maintainers across multiple geographies, we need to move this process to async.
This PR adds a Go/No-Go issue template that enables async voting: