Sig-release: Create a shadowing retrospective

[alejandrox1]

At the end of every release, the release team holds a retrospective to discuss what went well, what could have gone better, and what will be done differently in the future.

A topic that has been brought up is that new members of the release team/community or attendees may not feel completely comfortable jumping into the conversations because it takes time to get acquainted with the people, the organization, and the processes.
Plus, because of the nature of the topics, it is often the case that the people with more context/feedback are the contributors who have been around the longest and those who feel comfortable speaking out.

Another potential item of that may affect who speaks out and about what is that the shadowing experience is not strictly the same as the overall release retrospective. The shadowing experience involves on top of all things learning - learning about the community, about the people, and about the nature of the work.

Thus, I wanted to open up this issue to bring out the topic of potentially creating a release retrospective-type event that is lead by shadows.
Such an event would provide the opportunity for shadows to meet the entire release team and chat away - the format of the normal release meetings doesn't completely allow for people to discuss the issues that affect their contributor experience.
Furthermore, such an event would provide us with an overall feedback on our mentoring efforts and shed light on areas that may need to be improved, learn what works well, etc.

With all that being written, I am interested in what everyone would think of such an event.
And if you are a shadow, are considering in applying to be a shadow, or have been a shadow, we would love to get your feedback :smiley:

/sig release
/area release-team
Also tagging sig contribex as this seems close to their area of focus
/sig contribex
/priority backlog
/milestone v1.18

[k8s-ci-robot]

@alejandrox1: The label(s) sig/contribex cannot be applied, because the repository doesn't have them

In response to this:

At the end of every release, the release team holds a retrospective to discuss what went well, what could have gone better, and what will be done differently in the future.

A topic that has been brought up is that new members of the release team/community or attendees may not feel completely comfortable jumping into the conversations because it takes time to get acquainted with the people, the organization, and the processes.
Plus, because of the nature of the topics, it is often the case that the people with more context/feedback are the contributors who have been around the longest and those who feel comfortable speaking out.

Another potential item of that may affect who speaks out and about what is that the shadowing experience is not strictly the same as the overall release retrospective. The shadowing experience involves on top of all things learning - learning about the community, about the people, and about the nature of the work.

Thus, I wanted to open up this issue to bring out the topic of potentially creating a release retrospective-type event that is lead by shadows.
Such an event would provide the opportunity for shadows to meet the entire release team and chat away - the format of the normal release meetings doesn't completely allow for people to discuss the issues that affect their contributor experience.
Furthermore, such an event would provide us with an overall feedback on our mentoring efforts and shed light on areas that may need to be improved, learn what works well, etc.

With all that being written, I am interested in what everyone would think of such an event.
And if you are a shadow, are considering in applying to be a shadow, or have been a shadow, we would love to get your feedback :smiley:

/sig release
/area release-team
Also tagging sig contribex as this seems close to their area of focus
/sig contribex
/priority backlog
/milestone v1.18

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mrbobbytables]

/sig contributor-experience

[droslean]

This a great idea. +1

[markyjackson-taulia]

I am +1 on this
/honk

[k8s-ci-robot]

@markyjackson-taulia:

In response to this:

I am +1 on this
/honk

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[guineveresaenger]

I confess to being in need of convincing.

My first thought is:

"Retrospective" is not the correct term for this, or at least comparing it to the RT retrospective is not a good idea. While I can see the point in creating a space for RT shadows to share and improve/give feedback to their experiences, I would much rather have an official mid-release check-in or two, facilitated by the EA. Let's course correct in case there are problems!

My reasons for thinking this is in general not a good idea, in no particular order:

• I want _everyone_ to be part of the retrospective. I do not, in any way, want to separate "leads" and shadows" into separate processes, _especially_ at the end of a release where many outgoing Shadows will be incoming Leads. The best Shadow experience is one where you take over the Lead's responsibility for a time, or for part of the workload. This is an explicit goal of the experience of being a Shadow. They are true, full members of the RT, and get responsibilities and thank-you swag just like anyone else.

• What problem are we trying to solve? If Shadows are intimidated by seemingly more experienced folks seemingly having more authority in the retrospective then we have a problem with experienced folks taking up too much space. The retrospective moderator needs to make sure everyone gets heard.

• Any issue that Shadows have should fall into two buckets: a) a communication issue with their Lead or another team member, or b) something related to their role. _Both should be addressed as part of the retrospective_. The Shadow Program's purpose is to keep the release team tribal knowledge alive and functioning. If something is awry, it is everyone's business.

[alejandrox1]

I would much rather have an official mid-release check-in or two, facilitated by the EA.

a mid-release check in would be good but getting feedback when its all done and settled is also important. The time difference enables for shadows to get more experience.
There is a steep learning curve for a lot of the work so getting feedback when shadows are more settle is crucial.

---

I want everyone to be part of the retrospective. I do not, in any way, want to separate "leads" and shadows" into separate processes

The intent is NOT to separate leads from shadows but to give a forum where shadows are expected to lead the conversation.
One factor that may influence whether people speak out during a release is just how much they know they people in the team. This event would give a chance for people to talk, meet everyone, and get the feeling for the team at large.
The idea would be to have shadows take the lead's responsibility for during this event.
And leads should attend and listen.

---

What problem are we trying to solve? If Shadows are intimidated by seemingly more experienced folks seemingly having more authority in the retrospective then we have a problem with experienced folks taking up too much space. The retrospective moderator needs to make sure everyone gets heard.

I'm going off the premise that there is a ton of work going on in the community, and experienced contributors work a lot and in many areas.
It is easier to jump in into topics if you have been part of multiple release teams, multiple releases, have contributed to multiple areas, etc.

The moderator can help make sure topics get properly covered but due to the immense amount of work and the fact that the most discussed problems tend to be the most complex it takes time for shadows to get experience in these troublesome areas.
Now, that is about the most discussed problems, the things that other contributors and users run into.
This does not mean that shadows do not run into problems but that the problems that shadows may run into are not very well observed due to the fact that it is tough to understand the painpoints of new contributors when we are not new contributors anymore.
We need to get more visibility into the issues that shadows may run into.

---

Any issue that Shadows have should fall into two buckets: a) a communication issue with their Lead or another team member, or b) something related to their role. Both should be addressed as part of the retrospective. The Shadow Program's purpose is to keep the release team tribal knowledge alive and functioning. If something is awry, it is everyone's business.

This is a big idea and motivation of why I wanted to proposed this.
To make sure that the problems that shadows are facing are not covered behind our needs to improve test coverage, reduce flakiness, enhance KEP information, design merging strategies, and the various other problems that are continuously discussed not only during the retrospective but during multiple releases.

Thank you for bringing up those points!

[alejandrox1]

/cc @lachie83
would love to hear your thoughts on this

[LappleApple]

Hiya, if the RT group wants some support on retrospective facilitation and meeting moderation I can either point you to some resources or even run a short retro facilitation session with some of you. If one of your goals is to make retros and similar meetings/exercises more inclusive, there are some lightweight steps you can take to achieve that. LMK if you'd either like some resources on this topic or if you want to chat.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[tpepper]

Considering this has grown stale, I wonder is this sufficiently covered by https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/emeritus-adviser#evaluation

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[alejandrox1]

Dropping a quick note on this one: along with gathering feedback on how the shadowing experience was going, part of the intent was on giving shadows a forum to chat and be heard - the usual retrospective doesn't give a lot of room for shadows to take part in with mentoring issues or to just talk about their experiences.
Also worth mentioning that I have never seen the results of the evaluation (have no insight to say push for a shadowing retrospective or an evaluation).

If we want to close out this issue, do we have a feeling to say that a form asking for an evaluation results in useful and actionable feedback? :eyes:

/cc @jeremyrickard @hasheddan @palnabarun @savitharaghunathan @lachie83

Removing the rotten lifecycle just to seek some actual conclusion.
/remove-lifecycle rotten

[lachie83]

I would suggest that we close this issue. Here are the two actions that we are going to take:

• Monthly lead sync to bubble up and challenges and identity possible communication issues
• Encourage more conversation to happen Slack between the leads and shadows

We will also continue the mid-cycle shadow feedback survey as a touch point but this also needs to be monitored for how actionable the feedback is. The goal of these changes was not to create another communication channel along with a separate meeting for shadows only.