---- On Wed, 13 Feb 2019 06:38:28 +0900 Colleen Murphy <colleen@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@gmail.com> wrote ----
On Mon, Feb 11, 2019 at 8:01 AM Thierry Carrez
Doug Hellmann wrote:
Kendall Nelson <kennelson11@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
willing to be contacted for helping people get started. It
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
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
<thierry@openstack.org> wrote: people probably just liaison 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