[tc] The future of the "Help most needed" list

Colleen Murphy colleen at gazlene.net
Tue Feb 12 21:38:28 UTC 2019


On Tue, Feb 12, 2019, at 9:21 AM, Ghanshyam Mann wrote:
>  ---- On Tue, 12 Feb 2019 02:14:56 +0900 Kendall Nelson 
> <kennelson11 at gmail.com> wrote ---- 
>  > 
>  > 
>  > On Mon, Feb 11, 2019 at 8:01 AM Thierry Carrez 
> <thierry at openstack.org> wrote:
>  > Doug Hellmann wrote:
>  >  > Kendall Nelson <kennelson11 at gmail.com> writes:
>  >  >> [...]
>  >  >> So I think that the First Contact SIG project liaison list kind 
> of fits
>  >  >> this. Its already maintained in a wiki and its already a list of 
> people
>  >  >> willing to be contacted for helping people get started. It 
> probably just
>  >  >> needs more attention and refreshing. When it was first set up we 
> (the FC
>  >  >> SIG) kind of went around begging for volunteers and then once we 
> maxxed out
>  >  >> on them, we said those projects without volunteers will have the 
> role
>  >  >> defaulted to the PTL unless they delegate (similar to how other 
> liaison
>  >  >> roles work).
>  >  >>
>  >  >> Long story short, I think we have the sort of mentoring things 
> covered. And
>  >  >> to back up an earlier email, project specific onboarding would be 
> a good
>  >  >> help too.
>  >  > 
>  >  > OK, that does sound pretty similar. I guess the piece that's 
> missing is
>  >  > a description of the sort of help the team is interested in 
> receiving.
>  >  
>  >  I guess the key difference is that the first contact list is more a 
>  >  function of the team (who to contact for first contributions in this 
>  >  team, defaults to PTL), rather than a distinct offer to do 1:1 
> mentoring 
>  >  to cover specific needs in a team.
>  >  
>  >  It's probably pretty close (and the same people would likely be 
>  >  involved), but I think an approach where specific people offer a 
>  >  significant amount of their time to one mentee interested in joining 
> a 
>  >  team is a bit different. I don't think every team would have 
> volunteers 
>  >  to do that. I would not expect a mentor volunteer to care for 
> several 
>  >  mentees. In the end I think we would end up with a much shorter list 
>  >  than the FC list.
>  > 
>  > I think our original ask for people volunteering (before we completed 
> the list with PTLs as stand ins) was for people willing to help get 
> started in a project and look after their first few patches. So I think 
> that was kinda the mentoring role originally but then it evolved? Maybe 
> Matt Oliver or Ghanshyam remember better than I do?    
> 
> Yeah, that's right. 
> 
>  >  Maybe the two efforts can converge into one, or they can be kept as 
> two 
>  >  different things but coordinated by the same team ?
>  >  
>  > 
>  > I think we could go either way, but that they both would live with 
> the FC SIG. Seems like the most logical place to me. I lean towards two 
> lists, one being a list of volunteer mentors for projects that are 
> actively looking for new contributors (the shorter list) and the other 
> being a list of people just willing to keep an eye out for the welcome 
> new contributor patches and being the entry point for people asking 
> about getting started that don't know anyone in the project yet (kind of 
> what our current view is, I think).  -- 
> 
> IMO, very first thing to make help-wanted list a success is, it has to 
> be uptodate per development cycle, mentor-mapping(or with example 
> workflow etc). By Keeping the help-wanted list in any place other than 
> the project team again leads to existing problem for example it will be 
> hard to prioritize, maintain and easy to get obsolete/outdated. FC SIG, 
> D&I WG are great place to market/redirect the contributors to the list. 
> 
> The model I was thinking is:
> 1. Project team maintain the help-wanted-list per current development 
> cycle. Entry criteria in that list is some volunteer mentor(exmaple 
> workflow/patch) which are technically closer to that topic.
> 2. During PTG/developer meetup, PTL checks if planned/discussed topic 
> needs to be in help-wanted list and who will serve as the mentor. 
> 3. The list has to be updated in every developement cycle. It can be 
> empty if any project team does not need help during that cycle or few 
> items can be carry-forward if those are still a priority and have mentor 
> mapping. 
> 4. FC SIG,  D&I WG, Mentoring team use that list and publish in all 
> possible place. Redirect new contributors to that list depends on the 
> contributor interested area. This will be the key role to make help-
> wanted-list success.
> 
> -gmann
> 
>  >  Thierry Carrez (ttx)
>  > 
>  > -Kendall (diablo_rojo)  
> 
> 
> 

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

Colleen



More information about the openstack-discuss mailing list