Wouter Verhelst:
On Sat, Oct 08, 2022 at 08:06:33AM +0200, Niels Thykier wrote: [...] OK, thanks. This was the reason why I added that disclaimer at the top of my previous email; if the release team doesn't want to do the work (which would be completely reasonable!) then obviously we'd have to create a new team.
Indeed - I noted that. :) My answer to Sam's email was due how it went into details with why Sam saw the RT as a good candidate team for this role and I wanted to present a counterargument to Sam's email.
Additionally, as an x-RT member that was present when release goals was axed. One of the reasons, why I supported axing release goals was that it was a lot of coordination and tracking on the RT side while the people proposing the goals often went "Sounds like you got this now, kthxbye" one the goal was accepted.Yeah, that's not helpful. I think the requirement of the team to actually do the work in my proposal (and the project even being rejected at the end of the release cycle if they don't do the work) should help in remedying that, though? Or do you have a different perspective?
The original release goals proposal already had as requirement that someone else was tracking the goal. Not sure whether we were explicit enough with it back then and the proposal here might be better at this.
However, even if it is more explicit, we continuously see conflict between people saying they are volunteering/doing a task and another side feeling these people are not doing "enough". This was the case between the "advocates" in release goals and me on the release team back in the day. It is every release between porters and one of the many stakeholders in architecture qualification.
This has a tendency of becoming very subjective - and subjective measurements tend to escalate conflicts in the cases where one side disagree with the measurement.
This is one of the arguments for having "SMART" release goals (with the "M" being "Measurable") back in the day. It still did not work that well because volunteer effort is hard to measure objectively. And this problem is very likely to show up for this proposal as well.
Obviously, there are some differences between this proposal and the old release goals - but at the end of the day, I still feel this is dropping a lot of extra work on the RT so people can use them as meatshields in their debate. To me that is an excellent way of burning out the Release Team and therefore I advice against it.Right, so it's not a job for the release team then. Makes sense.
> [...]At the end of the day, I think the release team should answer themselves whether they want to accept it - I do not and should not speak on their behalf. However, looking at this from the release team point of view, I cannot see a single reason why they would want this extra responsibility. Accordingly, I would expect them to say "No thank you" and I recommend people not building this proposal around the RT taking this role (or at least have a contingency plan for the RT saying "No thank you").
Thanks, ~Niels