Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Release Team Selection (Shadow questionnaire) #433

Merged
merged 1 commit into from Jan 10, 2019

Conversation

@justaugustus
Copy link
Member

commented Jan 9, 2019

Fixes: #368

Signed-off-by: Stephen Augustus saugustus@vmware.com

/assign @spiffxp @BenTheElder @marpaia @jberkus

@k8s-ci-robot k8s-ci-robot requested review from jberkus and kacole2 Jan 9, 2019

@justaugustus justaugustus force-pushed the justaugustus:rt-selection branch 2 times, most recently from d4d1992 to 8750816 Jan 9, 2019

@justaugustus justaugustus changed the title [WIP] Update Release Team Selection (Shadow questionnaire) Update Release Team Selection (Shadow questionnaire) Jan 9, 2019

Show resolved Hide resolved release-team/release-team-selection.md Outdated
- The purpose of shadowing is to train new Release Team members. Assuming that your job or life situations don't change between now and then, are you willing to volunteer for the relevant role Lead position for 1.15 or 1.16? This usually requires support from your employer, as you will probably need to do release work during work hours.
- What time zone are you usually in?

#### Experience

This comment has been minimized.

Copy link
@marpaia

marpaia Jan 9, 2019

Member

As a former release notes lead, I think it's really useful to have one shadow with programming experience and one shadow with copy-editing / technical writing experience. Should we include these kinds of questions in the questionnaire?

This comment has been minimized.

Copy link
@justaugustus

justaugustus Jan 9, 2019

Author Member

@jberkus' initial intent was to have multiple questionnaires with role-specific information. I thought at this stage, it would be better to have a very generic survey that can apply to all roles with specifics about the role in the relevant role handbook. That's why one of the questions explicitly asks you to read the role handbook before continuing.

From a visibility/management perspective, I think it's also better to keep the handbook as the source of truth for role-specific requirements.

- are members of the relevant SIGs for their role, if applicable
- have some prior experience with contributing to Kubernetes (such as shadowing a role for a prior release)

Most importantly, strive for diversity in:

This comment has been minimized.

Copy link
@BenTheElder

BenTheElder Jan 9, 2019

Member

somewhat orthogonal, but outreach to this effect would be a nice SIG subproject, if we get anything more official together for that we should link to it here :-)

This comment has been minimized.

Copy link
@justaugustus

justaugustus Jan 9, 2019

Author Member

For sure. Love that idea, @BenTheElder!

Show resolved Hide resolved release-team/release-team-selection.md
Show resolved Hide resolved release-team/release-team-selection.md

@justaugustus justaugustus force-pushed the justaugustus:rt-selection branch from 8750816 to c1a1b82 Jan 9, 2019


- What [Release Team role(s)](https://git.k8s.io/sig-release/release-team#kubernetes-release-team-roles) are you interested in shadowing? _[Select up to two (2)]_
- The [Role Handbooks](https://git.k8s.io/sig-release/release-team/role-handbooks) defines the tasks and responsibilities of each role for this release cycle. Are you prepared to assist in fulfilling these duties? Please read the handbook relevant to the role you're interested in before answering.
- Shadowing Release Team roles requires a substantial time commitment, especially during the periods specified in your role handbook. The time requirements specified are estimates and depending on the need, you may need to dedicate more time than initially estimated. This may include attending video meetings at inconvenient times. Is this time you can commit to?

This comment has been minimized.

Copy link
@tpepper

tpepper Jan 9, 2019

Contributor

I strongly suggest also including explicit wording here around insuring your commitment is aligned with and supported with other possible commitments with an employer.

@tpepper

tpepper approved these changes Jan 9, 2019

Copy link
Contributor

left a comment

Generally looks sufficient to me, although I have made a few small suggestions for things I'd like to seem a bit more explicit in the questionnaire.

Show resolved Hide resolved release-team/release-team-selection.md

- What [Release Team role(s)](https://git.k8s.io/sig-release/release-team#kubernetes-release-team-roles) are you interested in shadowing? _[Select up to two (2)]_
- The [Role Handbooks](https://git.k8s.io/sig-release/release-team/role-handbooks) defines the tasks and responsibilities of each role for this release cycle. Are you prepared to assist in fulfilling these duties? Please read the handbook relevant to the role you're interested in before answering.
- Shadowing Release Team roles requires a substantial time commitment, especially during the periods specified in your role handbook. The time requirements specified are estimates and depending on the need, you may need to dedicate more time than initially estimated. This may include attending video meetings at inconvenient times. Is this time you can commit to?

This comment has been minimized.

Copy link
@aleksandra-malinowska

aleksandra-malinowska Jan 9, 2019

Contributor

I would prefer more precise wording than "may require... inconvenient times". It's one thing if we're talking once a week call at 8pm, another if it's a daily burndown meeting at 1am (which can happen if someone is based in Asia). Expecting all candidates to be fully available at undisclosed times and frequency feels unnecessary, and may end up rather exclusionary, given that the meetings are always scheduled in PST-friendly time.

This comment has been minimized.

Copy link
@justaugustus

justaugustus Jan 9, 2019

Author Member

@aleksandra-malinowska -- Good points. Where do you think we can strike a balance, while being careful not to be exclusionary?

Some things I think/know/feel:

  • We have some flexibility on who attends the meetings (lead, shadow, some combination of both). Doesn't need to be everyone, all the time. As long as the role has coverage for required activities, then I think that's fine.
  • PST-friendly is unfortunately the nature of the beast at the moment, though we should see what we can do to make that more inclusive for everyone. Do you think it's enough to mention US Pacific in the survey?
  • We used may require... inconvenient times to suggest that the times could also be convenient for you. Consider someone who could only volunteer during working hours, due to other commitments. If their working hours happen to be US-centric, then the RT meetings actually could be convenient for them. I want to make sure the language is inclusive of people with commitment restrictions, not just timezone restrictions.
  • It's hard to nail down exactly when meetings will be. We have, in the past, taken polls (h/t @AishSundar / @tpepper) to determine when we should hold the meetings, but that's really only possible after the team is formed and the RT Lead has a chance to chat with people about timezones. That said, I wouldn't feel comfortable implying times ahead of time.

This comment has been minimized.

Copy link
@tpepper

tpepper Jan 9, 2019

Contributor

We do need to be thinking about formalizing release team as more than PST-dominated. By leaving it open it's almost self-fulfilling in who volunteers and follows through.

This comment has been minimized.

Copy link
@justaugustus

justaugustus Jan 9, 2019

Author Member

Agreed.

@justaugustus justaugustus force-pushed the justaugustus:rt-selection branch from c1a1b82 to 4335abc Jan 9, 2019

@justaugustus

This comment has been minimized.

Copy link
Member Author

commented Jan 9, 2019

@tpepper / @aleksandra-malinowska -- updated with a blurb about US Pacific timezone-favoring and something on employer approval.

@tpepper -- Added questions at the end about past experience and goals for participating.

Update Release Team Selection criteria
Signed-off-by: Stephen Augustus <saugustus@vmware.com>

@justaugustus justaugustus force-pushed the justaugustus:rt-selection branch from 4335abc to 92c82f0 Jan 9, 2019

@spiffxp
Copy link
Member

left a comment

Nits that I won't hold this PR up for, I'd rather see this questionnaire get out the door. But nits to keep in mind as we decide whether to continue using this.

@@ -0,0 +1,102 @@
# Release Team Selection

In addition to discharging the duties of their respective Release Team roles, the current Release Team is charged with selecting the team for the following release cycle.

This comment has been minimized.

Copy link
@spiffxp

spiffxp Jan 9, 2019

Member

Subtle nit: I think the current release team has a very powerful say in who should be on the next release team. But I feel like creating/staffing the next release team is the responsibility of SIG Release (or the owners of the release team subproject). eg: Neither Aish nor I have been opening up release-team staffing PR's or issues for this release team, but we have been consulted

I won't hold this PR back for this, but suggest we follow up.

This comment has been minimized.

Copy link
@justaugustus

justaugustus Jan 9, 2019

Author Member

Will take a note to follow up on this.


### Timing

Staff early! The Release Team should undertake the selection process at the beginning of Code Freeze, with a deadline of three days following the current release.

This comment has been minimized.

Copy link
@spiffxp

spiffxp Jan 9, 2019

Member

Three days following current release is unrealistic, unless you're talking leads only. Going back to 1.10, release teams aren't finalized until the end of week 2.

This comment has been minimized.

Copy link
@justaugustus

justaugustus Jan 9, 2019

Author Member

We can follow up on this.

#### Logistics

- What [Release Team role(s)](https://git.k8s.io/sig-release/release-team#kubernetes-release-team-roles) are you interested in shadowing? _[Select up to two (2)]_
- The [Role Handbooks](https://git.k8s.io/sig-release/release-team/role-handbooks) defines the tasks and responsibilities of each role for this release cycle. Are you prepared to assist in fulfilling these duties? You must read the handbook relevant to the role you're interested in before answering.

This comment has been minimized.

Copy link
@spiffxp

spiffxp Jan 9, 2019

Member

This is a rubber stamp question. How do I know they've read the handbook? Again, I won't hold up for this.

But consider questions that demonstrate a bit of comprehension, eg:

  • "how many hours a week do you think you'll need to fulfill these duties?"
  • "which parts interest you most?"
  • "which parts interest you least?"

This comment has been minimized.

Copy link
@justaugustus

justaugustus Jan 9, 2019

Author Member

I'm inclined to hope that people are responding factually on the questionnaire, and by extension, have actually read the relevant handbooks. I generalized some of the questions so it can be used for all roles.

...just want to make sure this is more like getting a baseline of the volunteer and less like grading a test.

The latter two make for good "exit interview" questions. Maybe we can have a post-release survey in future?


Moving to a [questionnaire](#sample-questionnaire) / survey format will allow us to capture more of the information required to vet potential shadows and well as begin to generate metrics around some of the Release Team processes.

Questionnaire creation will be facilitated by SIG Release Chairs or a delegated coordinator to ensure consistency across release cycles.

This comment has been minimized.

Copy link
@AishSundar

AishSundar Jan 9, 2019

Contributor

Do we want to recommend a rough timeframe by which we want
(i) the questionairre to be sent out
(ii) 1:1 discussions completed between section leads and prospective shadows
(iii) Official shadows locked down?

This comment has been minimized.

Copy link
@justaugustus

justaugustus Jan 9, 2019

Author Member

@AishSundar -- I think it's hard to do that at the moment, as the timelines may be shifting this release e.g., maybe nixing Code Slush. Let's assess this once the cycle kicks off.

@spiffxp

This comment has been minimized.

Copy link
Member

commented Jan 10, 2019

/lgtm
to get this out the door, this is the survey we have, the longer we wait, the more likely this is all going to boil down to 1:1 convos anyway

@k8s-ci-robot k8s-ci-robot added the lgtm label Jan 10, 2019

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justaugustus, spiffxp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot merged commit 18d2f0f into kubernetes:master Jan 10, 2019

2 checks passed

cla/linuxfoundation justaugustus authorized
Details
tide In merge pool.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.