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.