Hi, We did something like this for the 1.14 release [1]. We did that in an async survey-style way approaching key contributors directly. I also think the output was quite nice and we got positive feedback for what we published. I think Robert mentioned they did something similar in the past, with a form-based survey with little feedback.
Just as an input. I still think "Flink Backward" is a great name for a retro. :) Best, Joe [1] https://flink.apache.org/2021/11/03/flink-backward.html On Wed, Nov 2, 2022 at 9:42 AM Qingsheng Ren <re...@apache.org> wrote: > Thanks for starting the discussion Matthias! > > I think having a retro after a release cycle would be quite helpful to > standardizing the procedure of the release, and also could avoid new > release managers getting stuck on the same issue that happened before. I > prefer the second option that RMs could open a discussion thread in ML at > the end of the release to collect feedback about the last release cycle and > add them to the release wiki page, which would be quite handy for further > RMs. > > Best, > Qingsheng > Ververica (Alibaba) > > On Mon, Oct 31, 2022 at 11:02 PM Matthias Pohl > <matthias.p...@aiven.io.invalid> wrote: > > > Hi everyone, > > I want to bring up the idea of having a retrospective on the release from > > the release manager's perspective. The idea would be to collect feedback > on > > what went well and what could be improved for a specific minor release. > So > > far, I didn't find anything on that topic. Does the community find this > > useful? Or was this already done but not helpful? > > > > I see three options here: > > 1. Having an actual meeting where issues can be discussed and/or > > experiences can be shared between the release managers of the previous > > release and the release managers of the next minor release. Of course, > this > > could be open to other contributors as well. A summary could be provided > in > > the Flink wiki (the Flink release's wiki article). > > 2. The release manager(s) provide a summary on the Flink release's wiki > > article as part of the release process. > > 3. Leave the process as is without any additional retrospective but focus > > on improving the documentation if issues arose during the release. > > > > That might help people who consider contributing to the community through > > supporting the release efforts. Additionally, it might help in > > understanding what went wrong in past releases retroactively (e.g. the > > longer release cycle for 1.15). > > > > I'm curious about opinion's on that topic. > > > > Best, > > Matthias > > >
