1:1 hour mentoring process improvements

[parispittman]

After conducting some tests and a retro, we discovered the following that needs to be corrected before a full scale launch can happen.

Automation
if the coordinator or person setting up the event is sick, ooto, etc., it will block the entire process. Getting this automation right is P0 or coming up with a team of people to coordinate.

Ideal workflow: [for all of this to happen in GitHub with an issue or PR template with full automation] mentee applies via some kind of form, mentor is auto-matched with limited to no human involvement (based on criteria below in the 3rd bullet), calendar is sent with populated information, meeting happens, everyone is happy

• figure out an automated flow between mentor to collect calendar availability and mentee to select from that. the back and forth that just the scheduling process causes is a huge bus factor and time hole.

• need to generate a "profile" and hopefully populate it in the calendar invite on information from the mentee's form with critical info that the mentor will need pre-session.
  Fields that need to be carried over:

Mentee Info

1. preferred name and pronouns, github id, slack id
2. 1:1 hour activity choice
3. $said_choice tools/misc
4. dev enviro set up?
5. exp with Go (if applicable)
6. exp with the following (q about yaml, containers, our testing infra, etc.)

Mentor Info (for mentees as fyi)

1. preferred name and pronouns, github id, slack id
2. what sig/wg(s) are you most active in

• a light match. Mentors will be trained that they will not be a perfect match ever and that it's important to teach the mentee how to be resourceful and learn together.
  Match on the following mandatory criteria: 1) timezone - need to be within three hours 2) 1:1 hour activity choice 3) $said_choice tools/misc 4) level on contributor ladder (must be => mentees; equal is perfectly acceptable) 5) *optional match: what sig are you interested in getting more involved

Process Improvement

• identify three recommended tools/ways of doing remote pair programming that would work for our environment.
  why? the mentor and mentee took significant time from the one hour trying to decide on what tool would work best for them and then they didn't do the pair. if we establish this upfront, or at least boil down the countless ways and have folks agree to those, it will save much needed time here.

• need to finesse all of the activity use cases and make sure that mentors are set up for success so we don't have another pair programming tool debacle. ie - if it's not pair programming and say an AMA, we need to document to use zoom, hangouts, etc. Take this decision away from the mentor/mentees to free up their time to work on the hard stuff.

• pair programming: add documentation about the mentee responsibility to bring a help wanted labeled issue (preferred) or an concept to half complete PR. The mentor needs a jumping off point so there isn't a long amount of back and forth.

• mentors need a script/instructions since this isn't your average mentoring session. definitely need a closing since it's only a one time session - how do you end the call? provide the mentee with other resources to check out, places to communicate, etc.

[parispittman]

@jeefy is working on an automated calendar widget that would be kicked off from an issue template

[misterikkit]

Thanks for distilling all this!

On the topic of automating calendar invites, might also be good to automate an email reminder 24h in advance.

For #s 5 and 6 on mentee info, I wonder if those can be turned into a more generic, "what level of help are you looking for?" that could range from dev enviro setup to code/config syntax to very specific k8s stuff.

Since you propose that mentees need to do more prep for pair programming, that might turn some contributors off. I still think it should be there, but we could provide an off-ramp where the contributor goes, "well I don't know what help-wanted issue or concept to work on" and the mentoring session can be about answering those questions instead.

[misterikkit]

Would this proposal force all mentees to make their requests public?

[parispittman]

Agreed to auto email reminders! That's a good one.

Re need an issue to work on: That's a suggested activity for mentor/ees to choice from now. "AMA" I need to get a script/doc together for the mentors that explains just that. I've been thinking about a "training", too, for mentors once we have more of this laid out since some of these concepts/way of doing this are new.

Re mentees public requests: We are playing around with that now. Ideally would like to make this as private as possible where personal info is concerned; at the very least have separate process or anonymous process for this reason.

[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

[mrbobbytables]

/remove-lifecycle stale

[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

[jeefy]

/remove-lifecycle stale

[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

[parispittman]

/remove-lifecycle stale

[markjacksonfishing]

@misterikkit would you be open to pairing with me on this task to drive it to completion?

[markjacksonfishing]

/assign markyjackson-taulia

[hh]

A Templated Startup Process

At @ii we use a templating system to capture our pairing worksflows based on org-mode.

We may find it useful to cherry pick some ideas from it and create a few templated ways to start a mentoring session.

It's also great in that the output is available in text, markdown and an html presentation.

It may get even more interesting if we integrate asciinema

https://github.com/kubemacs/kubemacs/tree/master/org/cncf/apisnoop#environment-for-docker-init

variables

We set some variables for the list of repositories, who is pairing together and the specific workflow/org file.

Note that our workflow has a test-writing.org as the target, which brings up an auditsink that logs to apisnoop so you have a way to query what your kubernetes interactions are doing in cluster as far as the groups and hopefully matching to sigs.

KUBEMACS_GIT_EMAIL=hh@ii.coop
KUBEMACS_GIT_NAME="Hippie Hacker"
KUBEMACS_TIMEZONE=Pacific/Auckland
KUBEMACS_INIT_DEFAULT_REPOS='https://github.com/hh/apisnoop.git'
KUBEMACS_INIT_ORG_FILE=apisnoop/test-writing.org

docker run to create local cluster

We start with only requiring docker, but we map the docker socket of the host, into the container, which includes kind + kubectl. We think invites to nearly anyone being able to do this locally, though we could just as easily use a k8s community hosted cluster.

This brings up kubemacs as a stateful-set so we know the name of the container is kubemacs-0

docker run \
       --env-file $ENV_FILE \
       --name kubemacs-docker-init \
       --user root \
       --privileged \
       --network host \
       --rm \
       -it \
       -v "$HOME/.kube:/tmp/.kube" \
       -v /var/run/docker.sock:/var/run/docker.sock \
       $KUBEMACS_IMAGE \
       docker-init.sh

kubectl exec attach

By default the above will connect and use osc52 to populate the clipboard with the content to paste to the other person.

I use the terminal via an OSC52 terminal, but the web works pretty good too. We are currently using @tmate-io

Both emacs and vim work quite well in cluster.

Another kiwi @chrisbarret made some software we use to explore the cluster from within emacs. kubernetes-el

tmate

Tmate provides both ssh and web urls. The ssh urls can be pasted directly into terminals. The tmate binary by default uses the services hosted by tmate.io.

I paired recently with the created of tmate @nviennot to ensure anyone could bring it up inside kind locally and just use a tmate.1.1.1.2.xip.io address successfully.

We should probably run a service at pairing.k8s.io and default our configuration to use it.

kustomization for pairing.k8s.io

I published my work with @nviennot here:

https://github.com/kubemacs/kubemacs/tree/master/manifests/tmate

But we would need to get wg-k8s-infra involved to run it there.

osc52 (kubectl exec populating clipboard)

Since we work in cluster, we need a way for the terminal to back-haul copy/paste to the OS clipboard over kubectl exec. If we use a browser, I think we won't need it, but I really like working in my local terminal.

While not necessary, it's nice to have OSC52 support, and each OS has at least one option. It should be noted that both vim and emacs support OSC52.

Linux

working

• xterm

not working (yet)

Most others are based on libvte, which still needs support.

• libvte: I opened gitlab.gnome.org/GNOME/vte#125](https://gitlab.gnome.org/GNOME/vte/-/issues/125)

Windows

working

• git-bash terminal

not working (yet)

• microsoft/terminal : See microsoft/terminal#2946
• Browsers: nassh
• Security discussions from 2017-2018
  • https://seclists.org/oss-sec/2017/q2/197
  • https://seclists.org/oss-sec/2018/q2/31

OSX

working

I can't recommend iTerm2 enough:

• iTerm2.app

not working (yet)

• Terminal.app that ships with OSX

[hh]

The last comment was created by exporting this file as markdown: https://github.com/humacs/humacs/blob/master/org/kubernetes/community/sig-contribex/mentoring-hour.org#mentoring-hour-improvements

[markjacksonfishing]

This is awesome. Thank you

[markjacksonfishing]

This is the concept I am thinking about.

1. Mentee wishing to be mentored fills out the google form. Via automation, a PR is opened with appropriate mentoring subproject labels.

2. Either manually or via automation, the form is matched with available mentors for the given SIG the mentee has requested

3. A doodle template is sent to the mentor who selects open slots and sends back to the mentee.

4. Mentee selects slot and via automation, a calendar invite is created and sent to both mentee and mentor.

5. Meeting happens

6. At the end of the day of the calendar invite a survey is sent to the mentee and mentor. Once both are received back, the issue is updated and put in status for review (or we can close it)

cc: @nikhita @idvoretskyi @parispittman @mrbobbytables

[hh]

/cc

[markjacksonfishing]

@nikhita @idvoretskyi Any thoughts on the above?

[markjacksonfishing]

Per @jberkus
For item 2:
Leave this manual so we can learn more about the process.

[markjacksonfishing]

Per @jberkus
3. A doodle template is sent to the mentor who selects open slots and sends back to the mentee.

• Add communication preference for the mentor
• If no response, an alert (can be email but slack is prob best) of some type is sent to the mentoring subproject

[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

[markjacksonfishing]

/remove-lifecycle stale

[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

[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-contributor-experience at kubernetes/community.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

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.