Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: selection process for Shadows #368
RT Section Lead/Shadow is a mentorship relationship, but we have not been treating it as one. Instead of having a process to select the most suitable mentees for a given cycle, we simply accept anyone who volunteers before a certain deadline, up to four shadows per lead. This has resulted in leads having too many shadows for them to manage, and shadows not being mentored for the role they are shadowing. Further, we have contributors volunteering to shadow without any clear idea of what they're committing to or what the requirements and expectations are.
We should have a semi-formal selection process, which should work as follows:
As a prerequisite to this, it would also be good to establish guidelines on how many shadows are the maximum practical for a given role. For example, CI signal can't really make use of more than 2 shadows, but Docs is capable of keeping up to 4 shadows busy.
This also begs the question of whether we should have a process for selecting section leads. To date, one hasn't seemed necessary because, unlike shadows, we have a shortage rather than a surplus of volunteers, and generally all section leads are well-known from prior release teams.
draft template for shadow questionnaire
You have asked to be a role Shadow for the ver Release Team. This questionnaire is to determine how well you match the position's requirements, and to give you an idea what's involved. In cases where there are too many applicants for a particular role, it may also be used to decide who is selected this release cycle. Please note that you are expected to be inexperienced in some areas, as Shadow is a mentored role.
Example: Issues/PR Triage requires a substantial time commitment, especially during the 2nd half of the release cycle (Nov. 5 to Dec. 5). This can be more than an hour a day, and may include attending video meetings at inconvenient times. Is this time you can commit to?
Example: Release Notes Shadow also requires editing and rewriting release notes, in English, to make them clearer and more accurate. Is this something you are comfortable with?
Example: What's your current experience and involvement with SIG-Testing, and automated tests in general?
referenced this issue
Nov 14, 2018
Spoke with @idvoretskyi and we'll plan to generate a SurveyMonkey survey for the questionnaire. I was originally thinking Google Forms, but the SurveyMonkey route should be more inclusive.
Won't be able to tackle this until after Thanksgiving though. This week is ruff.
In response to this:
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.
What do you think about having a "small, contained and relevant" task that potential shadows could go through as part of the volunteering/selection process?
I could see this helping with 3 things:
 "small, contained and relevant":
Patch release duties are mostly independent of the branch and can be done by any patch release manager. I suggest we have a patch release team instead of individual managers. Each member can still be responsible for one release but all of the team would be in sync with everything on all active releases and every member of the team will also have the ability to do the release. In the case of security releases, one team member can take care of all releases (as the jobs can be run in parallel and it is mostly busy work). If the release toke longer than working day of that person, it can be transferred to another member of the team in an appropriate timezone.