Open Stack

 ---- On Wed, 13 Feb 2019 06:38:28 +0900 Colleen Murphy <colleen at gazlene.net> wrote ---- 
 > 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. 

Thanks for writing it in a clear and with details which really help. +1 on not maintaining
it on mentoring or FC group side. I completely agree with this. 

The main reason why I vote to maintain it on the projects side is that gives ownership
to the right people who actually need help. "Project_X need help, so they create and maintain
this list with proper mentor mapping".  They eventually get help if they maintain it
well with up to date item with mentor mapping. I am sure that most of the time,
mentor to the list items will be from the project team (I assume very few cases can be
from SIG or TC), which makes PTL or other leaders in the project team as good
candidate to manage the list than any central team.

This idea changes this list towards project wise help wanted from openstack
wise help wanted ( *openstack-*help-wanted -> *project-*help-wanted ) which
I feel should not be a concern as long as it serves the purpose of getting help and
complete some item.

Template or best place to link that list (in contributor doc or spec repo or in home page etc) is
something we can discuss as a second step.

TC maintaining this list is not so helpful or valuable in past. But Yes, the idea of peer-mentoring
is something much-need pre-condition for such effort either it is corporate or open source. 
I am ok with trying it under TC with peer-mentoring idea and see how it goes. 
Key point will be how closely the project teams involved in this effort with TC. If we win
in that step then, we can see some outcome. 

-gmann

 >  
 > 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 
 >  
 >