Consider multiple retrospectives during the cycle rather than 3 at the end

[saschagrunert]

The idea is to move the retrospectives from the end of the cycle to the second half of it. This provides faster feedback loops to catch-up on issues and follow-ups. It also enables the team to solve possible problems directly during the cycle rather than handing them over to the next team, which they're probably not part of.

Thoughts on that @kubernetes/release-team-leads ?

[jeremyrickard]

I personally like this idea. With 1.23 especially, the retros will fall pretty late into December (considering when people start to be unavailable for holiday vacations).

Doing them earlier will allow for better course correction and problem solving during the cycle, and might make for more opportunities for RT members to contribute during the cycle and be more engaged.

[reylejano]

+1 to having a retro during the cycle specially. This is more important with last release cycle at the end of the year as there are multiple holidays.

[justaugustus]

How about immediately as we head into burndown?

[justaugustus]

(Reply here to discuss timeline)

[jrsapi]

+1 to burndown. The enhancement team's role will be about complete, and if there are any changes for the enhancement team this early start would provide time for them to implement before the next release cycle starts.

[reylejano]

+1 to starting at burndown. How about coupling the first burndown meeting as the first retro?
If we have a retro during the 1.23 cycle, this would be Monday, Nov 1.
If Monday is not preferred, how about the Wed or Fri burndown meeting of the first week of burndown?

[reylejano]

On #sig-release Slack, we will have the first retro of the 1.23 cycle on Wed, Nov 3

[reylejano]

PR #1706 updates the 1.23 cycle calendar and moves the first retro to Wed, Nov 3 in week 11 of the release cycle

[justaugustus]

cc: @kubernetes/sig-release-leads

[palnabarun]

+1 to this idea!

It will help to implement anything that the team wants to improve in the current cycle itself.

[puerco]

Exactly and help folks maneuver mid-cycle in a much more coordinated fashion.

[jdumars]

+1 to more iterative retros for releases

When I originally started the release-wide retro (1.4 I believe?), it was a much smaller crew of folks involved. I think more frequent retrospectives will provide actionable feedback for the in-progress cycles. I do think we should continue full-release retros that allow for community and non-SIG input, so we can optimize independently for each.