Skip to content

release steps: stop posting milestone triage messages

Created by: slimsag

Today our release process has us posting these messages to most GitHub issues before the release https://github.com/sourcegraph/sourcegraph/issues/13792#issuecomment-692254942

Dear all,

This is your release captain speaking. 🚂🚂🚂

Branch cut for the 3.20 release is scheduled for tomorrow.

Is this issue / PR going to make it in time? Please change the milestone accordingly. When in doubt, reach out!

Thank you

I have multiple issues with this:

  1. It makes releases eventful and the wording appears to be putting pressure to land a change ASAP ("release is tomorrow, is this going to make it?") which is not what I want.
  2. It is spammy, and I do not think many people take action on it.

My proposal is to stop posting these messages all together and remove that step/script from our release process:

  • Use ./dev/release-ping.sh to ping teammates who have open issues or PRs in the milestone to ask them to triage those that won't make it into the release. ...
  • Review all other open issues in the milestone and ask assignees to triage them to a different milestone (preferring Backlog).

Individual teams are then responsible for updating milestones on issues are part of their planning - which they are (or are not) already doing today.


Related Slack thread https://sourcegraph.slack.com/archives/C02FSM7DU/p1600112057111500

@efritz says:

Have/do engineers find the branch-cut-imminent reminder being posted to each open issue in the milestone useful?

@rvantonder says:

No.

@unknwon says:

For individual issues, it is useful, but the email spam it causes outweighs the usefulness for me.

@efritz says:

How do you find it useful? I’d like to understand the benefit others see in it.

@unknwon says:

Personally I use it as a signal to post a status update comment, basically decide should I

  1. Put into backlog if priority dropped
  2. Move to candidate list for next iteration if still a priority but no bandwidth
  3. I'm currently working on it as last few items for the iteration, confident to ship, ignore the comment (also true for items only meaningful for Sourcegraph Cloud, which doesn't really care the branch cut). With that said, current "reminder comments" is not the only way to achieve what I've been using it for. (so if it annoys most of us, I'm positive to remove it)

@efritz says:

That makes sense. Do you think it’s a better reminder on the issue rather than having some other signal (branch cut is on calendar, announced in slack, etc) that won’t necessarily stick itself inside of an issue discussion?

@keegancsmith says:

I think in theory the idea is if your issue was supposed to be completed in that milestone, you should hopefully have everyone closed or just one or two that get commented on. So this encourages breaking down longer issues into smaller issues which just target a single milestone. The downside of this is it somewhat dictates how you manage and plan your issues, the upside is when looking at the issues as an outsider for a milestone you can be confident is the expectation is to actually get all that work done.

cc @sourcegraph/distribution please discuss