Open Stack

On 13/02/19 10:38 AM, Colleen Murphy wrote:
> I feel like there is a bit of a disconnect between what the TC is asking for
> and what the current mentoring organizations are designed to provide. Thierry
> framed this as a "peer-mentoring offered" list, but mentoring doesn't quite
> capture everything that's needed.
> 
> Mentorship programs like Outreachy, cohort mentoring, and the First Contact SIG
> are oriented around helping new people quickstart into the community, getting
> them up to speed on basics and helping them feel good about themselves and
> their contributions. The hope is that happy first-timers eventually become
> happy regular contributors which will eventually be a benefit to the projects,
> but the benefit to the projects is not the main focus.
> 
> The way I see it, the TC Help Wanted list, as well as the new thing, is not
> necessarily oriented around newcomers but is instead advocating for the
> projects and meant to help project teams thrive by getting committed long-term
> maintainers involved and invested in solving longstanding technical debt that
> in some cases requires deep tribal knowledge to solve. It's not a thing for a
> newbie to step into lightly and it's not something that can be solved by a
> FC-liaison pointing at the contributor docs. Instead what's needed are mentors
> who are willing to walk through that tribal knowledge with a new contributor
> until they are equipped enough to help with the harder problems.
> 
> For that reason I think neither the FC SIG or the mentoring cohort group, in
> their current incarnations, are the right groups to be managing this. The FC
> SIG's mission is "To provide a place for new contributors to come for
> information and advice" which does not fit the long-term goal of the help
> wanted list, and cohort mentoring's four topics ("your first patch", "first
> CFP", "first Cloud", and "COA"[1]) also don't fit with the long-term and deeply
> technical requirements that a project-specific mentorship offering needs.
> Either of those groups could be rescoped to fit with this new mission, and
> there is certainly a lot of overlap, but my feeling is that this needs to be an
> effort conducted by the TC because the TC is the group that advocates for the
> projects.
> 
> It's moreover not a thing that can be solved by another list of names. In addition
> to naming someone willing to do the several hours per week of mentoring,
> project teams that want help should be forced to come up with a specific
> description of 1) what the project is, 2) what kind of person (experience or
> interests) would be a good fit for the project, 3) specific work items with
> completion criteria that needs to be done - and it can be extremely challenging
> to reframe a project's longstanding issues in such concrete ways that make it
> clear what steps are needed to tackle the problem. It should basically be an
> advertisement that makes the project sound interesting and challenging and
> do-able, because the current help-wanted list and liaison lists and mentoring
> topics are too vague to entice anyone to step up.
> 
> Finally, I rather disagree that this should be something maintained as a page in
> individual projects' contributor guides, although we should certainly be
> encouraging teams to keep those guides up to date. It should be compiled by the
> TC and regularly updated by the project liaisons within the TC. A link to a
> contributor guide on docs.openstack.org doesn't give anyone an idea of what
> projects need the most help nor does it empower people to believe they can help
> by giving them an understanding of what the "job" entails.
> 
> [1] https://wiki.openstack.org/wiki/Mentoring#Cohort_Mentoring

This one email has pretty much completely changed my mind from "surely 
the FC SIG would have much more expertise here" to "maybe the TC does 
need to play a role".

I think if the TC had a strong idea of what a useful posting would look 
like, then the overhead of having the TC as gatekeeper and putting it in 
the governance repo (where docs go to die) would be worth it. Right now, 
I'm not sure we have that though. TBH I'm not sure we have any idea what 
we're doing - having so far only found a way that definitely does not 
work and indeed was so wide of the mark that it generated virtually no 
feedback about how to improve - but I'm willing to have another go :)

Colleen offers some good ideas above: it should be interesting, 
challenging, do-able, not vague. We've talked on IRC about the board's 
suggestion to include a business case like a job req might; perhaps that 
should be in the mix. We should say exactly who we're targeting - is it 
folks new to the community or those who have been around for a while but 
are looking for a project to sink their teeth into? Is it folks employed 
to work full-time upstream, or OpenStack operators who have a little 
time to contribute to upstream, or hobbyists?

If we could come up with a 'How to write an excellent mentoring offer" 
guide that could both explain to teams how to do it well and why we 
expect that to make a different as well as help the TC to review those 
proposals consistently, then I'd feel a lot more confident about making 
the TC the gatekeeper.

cheers,
Zane.