Thanks for all the insights on how it was done in the past and the pro's and con's of the different approaches. ...also being reminded on how we did it for 1.14 and the positive feedback we got from it was helpful.
I like the idea of an async survey. I also think that utilizing the mailing list for this sounds reasonable and doesn't add too much effort. Encouraging developers to reply to the release announcement in the ML might be a good place to not only congratulate but also give feedback on what could be improved. We could try that out and see (as a follow-up step) whether it makes sense to formalize it even more by providing a questionnaire form as suggested by Martijn. I would volunteer in updating the announcement template in the wiki [1] adding a sentence explicitly asking for feedback on the release. Additionally, the 1.17 release managers are planning to update the release management documentation [2] to give better guidance on what is expected from a release manager. That documentation should also include collecting feedback retroactively on a release. WDYT? Matthias [1] https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release [2] https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+Management On Thu, Nov 3, 2022 at 11:08 AM Johannes Moser <johan...@moser.wtf> wrote: > 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 > > > > > >
