[tc] The future of the "Help most needed" list
Hi everyone,
The "Help most needed" list[1] was created by the Technical Committee to clearly describe areas of the OpenStack open source project which were in the most need of urgent help. This was done partly to facilitate communications with corporate sponsors and engineering managers, and be able to point them to an official statement of need from "the project".
[1] https://governance.openstack.org/tc/reference/help-most-needed.html
This list encounters two issues. First it's hard to limit entries: a lot of projects teams, SIGs and other forms of working groups could use extra help. But more importantly, this list has had a very limited impact -- new contributors did not exactly magically show up in the areas we designated as in most need of help.
When we raised that topic (again) at a Board+TC meeting, a suggestion was made that we should turn the list more into a "job description" style that would make it more palatable to the corporate world. I fear that would not really solve the underlying issue (which is that at our stage of the hype curve, no organization really has spare contributors to throw at random hard problems).
So I wonder if we should not reframe the list and make it less "this team needs help" and more "I offer peer-mentoring in this team". A list of contributor internships offers, rather than a call for corporate help in the dark. I feel like that would be more of a win-win offer, and more likely to appeal to students, or OpenStack users trying to contribute back.
Proper 1:1 mentoring takes a lot of time, and I'm not underestimating that. Only people that are ready to dedicate mentoring time should show up on this new "list"... which is why it should really list identified individuals rather than anonymous teams. It should also probably be one-off offers -- once taken, the offer should probably go off the list.
Thoughts on that? Do you think reframing help-needed as mentoring-offered could help? Do you have alternate suggestions?
Huge +1 from me.
If the team want help, they need to offer some help first. We could also work with kinds of internship programmes like Outreachy.
Cheers, Lingxian Kong
On Thu, Jan 31, 2019 at 11:48 PM Thierry Carrez thierry@openstack.org wrote:
Hi everyone,
The "Help most needed" list[1] was created by the Technical Committee to clearly describe areas of the OpenStack open source project which were in the most need of urgent help. This was done partly to facilitate communications with corporate sponsors and engineering managers, and be able to point them to an official statement of need from "the project".
[1] https://governance.openstack.org/tc/reference/help-most-needed.html
This list encounters two issues. First it's hard to limit entries: a lot of projects teams, SIGs and other forms of working groups could use extra help. But more importantly, this list has had a very limited impact -- new contributors did not exactly magically show up in the areas we designated as in most need of help.
When we raised that topic (again) at a Board+TC meeting, a suggestion was made that we should turn the list more into a "job description" style that would make it more palatable to the corporate world. I fear that would not really solve the underlying issue (which is that at our stage of the hype curve, no organization really has spare contributors to throw at random hard problems).
So I wonder if we should not reframe the list and make it less "this team needs help" and more "I offer peer-mentoring in this team". A list of contributor internships offers, rather than a call for corporate help in the dark. I feel like that would be more of a win-win offer, and more likely to appeal to students, or OpenStack users trying to contribute back.
Proper 1:1 mentoring takes a lot of time, and I'm not underestimating that. Only people that are ready to dedicate mentoring time should show up on this new "list"... which is why it should really list identified individuals rather than anonymous teams. It should also probably be one-off offers -- once taken, the offer should probably go off the list.
Thoughts on that? Do you think reframing help-needed as mentoring-offered could help? Do you have alternate suggestions?
-- Thierry Carrez (ttx)
On Fri, 2019-02-01 at 00:32 +1300, Lingxian Kong wrote:
Huge +1 from me.
If the team want help, they need to offer some help first. We could also work with kinds of internship programmes like Outreachy.
Cheers, Lingxian Kong
On Thu, Jan 31, 2019 at 11:48 PM Thierry Carrez thierry@openstack.org wrote:
Hi everyone,
The "Help most needed" list[1] was created by the Technical Committee to clearly describe areas of the OpenStack open source project which were in the most need of urgent help. This was done partly to facilitate communications with corporate sponsors and engineering managers, and be able to point them to an official statement of need from "the project".
[1] https://governance.openstack.org/tc/reference/help-most-needed.html
This list encounters two issues. First it's hard to limit entries: a lot of projects teams, SIGs and other forms of working groups could use extra help. But more importantly, this list has had a very limited impact -- new contributors did not exactly magically show up in the areas we designated as in most need of help.
When we raised that topic (again) at a Board+TC meeting, a suggestion was made that we should turn the list more into a "job description" style that would make it more palatable to the corporate world. I fear that would not really solve the underlying issue (which is that at our stage of the hype curve, no organization really has spare contributors to throw at random hard problems).
So I wonder if we should not reframe the list and make it less "this team needs help" and more "I offer peer-mentoring in this team". A list of contributor internships offers, rather than a call for corporate help in the dark. I feel like that would be more of a win-win offer, and more likely to appeal to students, or OpenStack users trying to contribute back.
Proper 1:1 mentoring takes a lot of time, and I'm not underestimating that. Only people that are ready to dedicate mentoring time should show up on this new "list"... which is why it should really list identified individuals rather than anonymous teams. It should also probably be one-off offers -- once taken, the offer should probably go off the list.
Thoughts on that? Do you think reframing help-needed as mentoring-offered could help? Do you have alternate suggestions?
perhaps but since this is the frist time i have heard of the help-needed list maybe we should jsut merge it into openstack-discuss and use a [help-needed] or [mentoring] lable so its more discoverably?
Sean Mooney wrote:
perhaps but since this is the frist time i have heard of the help-needed list maybe we should jsut merge it into openstack-discuss and use a [help-needed] or [mentoring] lable so its more discoverably?
Oh, this is not a mailing-list. It's just a published document:
https://governance.openstack.org/tc/reference/help-most-needed.html
Source lives at: http://git.openstack.org/cgit/openstack/governance/tree/reference/help-most-...
On 2019-01-31 11:45:25 +0100 (+0100), Thierry Carrez wrote: [...]
I wonder if we should not reframe the list and make it less "this team needs help" and more "I offer peer-mentoring in this team". A list of contributor internships offers, rather than a call for corporate help in the dark.
[...]
It would be good to better understand how this differs from or otherwise relates to the current "cohort mentoring" activities in the community. Would we ask them to advertise cohorts in the proposed new document, or combine efforts with other mentor volunteers who use the new framework?
https://wiki.openstack.org/wiki/Mentoring#Cohort_Mentoring
+ openstack-mentoringOn Thu, 2019-01-31 at 11:45 +0100, Thierry Carrez wrote:
Hi everyone,
The "Help most needed" list[1] was created by the Technical Committee to clearly describe areas of the OpenStack open source project which were in the most need of urgent help. This was done partly to facilitate communications with corporate sponsors and engineering managers, and be able to point them to an official statement of need from "the project".
[1] https://governance.openstack.org/tc/reference/help-most- needed.html
TIL - will start sharing this with our mentees when they sign up.
This list encounters two issues. First it's hard to limit entries: a lot of projects teams, SIGs and other forms of working groups could use extra help. But more importantly, this list has had a very limited impact -- new contributors did not exactly magically show up in the areas we designated as in most need of help.
When we raised that topic (again) at a Board+TC meeting, a suggestion was made that we should turn the list more into a "job description" style that would make it more palatable to the corporate world. I fear that would not really solve the underlying issue (which is that at our stage of the hype curve, no organization really has spare contributors to throw at random hard problems).
So I wonder if we should not reframe the list and make it less "this team needs help" and more "I offer peer-mentoring in this team". A list of contributor internships offers, rather than a call for corporate help in the dark. I feel like that would be more of a win-win offer, and more likely to appeal to students, or OpenStack users trying to contribute back.
We've got a list of folks now who have volunteered to be mentors for various topics but we've struggled to get mentees and mentors engaged with each other and the program. There seems to be a hurdle between "I need/want to help" and active participation. A list of "this team needs this specific help" might actually be beneficial to getting people active, whereas I don't know that we'd gain much from another list of people who are generally open to helping (as much as that willingness to help is appreciated).
Proper 1:1 mentoring takes a lot of time, and I'm not underestimating that. Only people that are ready to dedicate mentoring time should show up on this new "list"... which is why it should really list identified individuals rather than anonymous teams. It should also probably be one-off offers -- once taken, the offer should probably go off the list. Thoughts on that? Do you think reframing help-needed as mentoring-offered could help? Do you have alternate suggestions?
Hopefully some of the folks who have signed up for the cohort mentoring program can share their thoughts here.
-jill
On Thu, Jan 31, 2019, at 7:00 PM, Jill Rouleau wrote:
- openstack-mentoringOn Thu, 2019-01-31 at 11:45 +0100, Thierry Carrez wrote:
Hi everyone,
The "Help most needed" list[1] was created by the Technical Committee to clearly describe areas of the OpenStack open source project which were in the most need of urgent help. This was done partly to facilitate communications with corporate sponsors and engineering managers, and be able to point them to an official statement of need from "the project".
[1] https://governance.openstack.org/tc/reference/help-most- needed.html
TIL - will start sharing this with our mentees when they sign up.
This list encounters two issues. First it's hard to limit entries: a lot of projects teams, SIGs and other forms of working groups could use extra help. But more importantly, this list has had a very limited impact -- new contributors did not exactly magically show up in the areas we designated as in most need of help.
When we raised that topic (again) at a Board+TC meeting, a suggestion was made that we should turn the list more into a "job description" style that would make it more palatable to the corporate world. I fear that would not really solve the underlying issue (which is that at our stage of the hype curve, no organization really has spare contributors to throw at random hard problems).
So I wonder if we should not reframe the list and make it less "this team needs help" and more "I offer peer-mentoring in this team". A list of contributor internships offers, rather than a call for corporate help in the dark. I feel like that would be more of a win-win offer, and more likely to appeal to students, or OpenStack users trying to contribute back.
We've got a list of folks now who have volunteered to be mentors for various topics but we've struggled to get mentees and mentors engaged with each other and the program. There seems to be a hurdle between "I need/want to help" and active participation. A list of "this team needs this specific help" might actually be beneficial to getting people active, whereas I don't know that we'd gain much from another list of people who are generally open to helping (as much as that willingness to help is appreciated).
This is a good point, I think for this reason it would be nice of the list was sort of a combination of the "job description" and peer-mentoring offer. It should be specific enough that people know beforehand whether it's something they would be interested in, and it should include specific objectives so people have something concrete to work towards and to measure their success against as they are working with their mentor.
Proper 1:1 mentoring takes a lot of time, and I'm not underestimating that. Only people that are ready to dedicate mentoring time should show up on this new "list"... which is why it should really list identified individuals rather than anonymous teams. It should also probably be one-off offers -- once taken, the offer should probably go off the list. Thoughts on that? Do you think reframing help-needed as mentoring-offered could help? Do you have alternate suggestions?
Hopefully some of the folks who have signed up for the cohort mentoring program can share their thoughts here.
As an Outreachy mentor I agree that 1:1 mentoring is a lot of work, and coming up with small-scope tasks for new people is really challenging. The problem with Outreachy is that often the interns go away when their internship is over, so something like this that encourages long-term growing of new contributors will ultimately be more rewarding for the community.
Colleen
-jill Email had 1 attachment:
- signature.asc 1k (application/pgp-signature)
---- On Thu, 31 Jan 2019 19:45:25 +0900 Thierry Carrez thierry@openstack.org wrote ----
Hi everyone,
The "Help most needed" list[1] was created by the Technical Committee to clearly describe areas of the OpenStack open source project which were in the most need of urgent help. This was done partly to facilitate communications with corporate sponsors and engineering managers, and be able to point them to an official statement of need from "the project".
[1] https://governance.openstack.org/tc/reference/help-most-needed.html
This list encounters two issues. First it's hard to limit entries: a lot of projects teams, SIGs and other forms of working groups could use extra help. But more importantly, this list has had a very limited impact -- new contributors did not exactly magically show up in the areas we designated as in most need of help.
When we raised that topic (again) at a Board+TC meeting, a suggestion was made that we should turn the list more into a "job description" style that would make it more palatable to the corporate world. I fear that would not really solve the underlying issue (which is that at our stage of the hype curve, no organization really has spare contributors to throw at random hard problems).
So I wonder if we should not reframe the list and make it less "this team needs help" and more "I offer peer-mentoring in this team". A list of contributor internships offers, rather than a call for corporate help in the dark. I feel like that would be more of a win-win offer, and more likely to appeal to students, or OpenStack users trying to contribute back.
Proper 1:1 mentoring takes a lot of time, and I'm not underestimating that. Only people that are ready to dedicate mentoring time should show up on this new "list"... which is why it should really list identified individuals rather than anonymous teams. It should also probably be one-off offers -- once taken, the offer should probably go off the list.
Thoughts on that? Do you think reframing help-needed as mentoring-offered could help? Do you have alternate suggestions?
Reframing to "mentoring-offered " is a nice idea which is something can give the best result if there will be. Being mentor few times or as FC SIG member, I agree that it is very hard to get new contributors, especially for the long term. Many times, they disappear after few weeks. Having a peer mentor can attract few contributors if they technically hesitate to start working on that.
Along with that we need this list as a live list and should be reiterated every cycle with the latest items, priority, peer-mentors mapping. For example, if any team adding any item as help-wanted do they provide peer-mentor or we ask the volunteer for peer-mentorship and based on that priority should go.
If I recall it correctly from Board+TC meeting, TC is looking for a new home for this list ? Or we continue to maintain this in TC itself which should not be much effort I feel. One of the TC members can volunteer on this and keep it up to date every cycle by organizing a forum sessions discussion etc. Further, we ask other groups like Outreachy, FC SIG, OUI to publishing this list every time they get chance to interact with new contributors.
-gmann
-- Thierry Carrez (ttx)
On 2019-02-04 17:31:46 +0900 (+0900), Ghanshyam Mann wrote: [...]
If I recall it correctly from Board+TC meeting, TC is looking for a new home for this list ? Or we continue to maintain this in TC itself which should not be much effort I feel.
[...]
It seems like you might be referring to the in-person TC meeting we held on the Sunday prior to the Stein PTG in Denver (Alan from the OSF BoD was also present). Doug's recap can be found in the old openstack-dev archive here:
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.htm...
Quoting Doug, "...it wasn't clear that the TC was the best group to manage a list of 'roles' or other more detailed information. We discussed placing that information into team documentation or hosting it somewhere outside of the governance repository where more people could contribute." (If memory serves, this was in response to earlier OSF BoD suggestions that retooling the Help Wanted list to be a set of business-case-focused job descriptions might garner more uptake from the organizations they represent.)
Jeremy Stanley fungi@yuggoth.org writes:
On 2019-02-04 17:31:46 +0900 (+0900), Ghanshyam Mann wrote: [...]
If I recall it correctly from Board+TC meeting, TC is looking for a new home for this list ? Or we continue to maintain this in TC itself which should not be much effort I feel.
[...]
It seems like you might be referring to the in-person TC meeting we held on the Sunday prior to the Stein PTG in Denver (Alan from the OSF BoD was also present). Doug's recap can be found in the old openstack-dev archive here:
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.htm...
Quoting Doug, "...it wasn't clear that the TC was the best group to manage a list of 'roles' or other more detailed information. We discussed placing that information into team documentation or hosting it somewhere outside of the governance repository where more people could contribute." (If memory serves, this was in response to earlier OSF BoD suggestions that retooling the Help Wanted list to be a set of business-case-focused job descriptions might garner more uptake from the organizations they represent.) -- Jeremy Stanley
Right, the feedback was basically that we might have more luck convincing companies to provide resources if we were more specific about how they would be used by describing the work in more detail. When we started thinking about how that change might be implemented, it seemed like managing the information a well-defined job in its own right, and our usual pattern is to establish a group of people interested in doing something and delegating responsibility to them. When we talked about it in the TC meeting in Denver we did not have any TC members volunteer to drive the implementation to the next step by starting to recruit a team.
During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team. Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on docs.openstack.org to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
So, maybe the next step is to convince someone to champion a goal of improving our contributor documentation, and to have them describe what the documentation should include, covering the usual topics like how to actually submit patches as well as suggestions for how to describe areas where help is needed in a project and offers to mentor contributors.
Does anyone want to volunteer to serve as the goal champion for that?
So, maybe the next step is to convince someone to champion a goal of improving our contributor documentation, and to have them describe what the documentation should include, covering the usual topics like how to actually submit patches as well as suggestions for how to describe areas where help is needed in a project and offers to mentor contributors.
Does anyone want to volunteer to serve as the goal champion for that?
This doesn't get visibility yet, as this thread is under [tc] only.
Lance and I will raise this in our next update (which should be tomorrow) if we don't have a volunteer here.
JP.
---- On Wed, 06 Feb 2019 18:45:03 +0900 Jean-Philippe Evrard jean-philippe@evrard.me wrote ----
So, maybe the next step is to convince someone to champion a goal of improving our contributor documentation, and to have them describe what the documentation should include, covering the usual topics like how to actually submit patches as well as suggestions for how to describe areas where help is needed in a project and offers to mentor contributors.
If I am not wrong, you are saying to have help-wanted-list owned by each project side which is nothing but a part of contributor documentation? As you mentioned that complete doc can be linked as a central page on docs.openstack.org. If so then, it looks perfect to me.
Further, that list can be updated/maintained with mentor mapping by the project team on every cycle which is nothing but what projects present in onboarding sessions etc.
Does anyone want to volunteer to serve as the goal champion for that?
This doesn't get visibility yet, as this thread is under [tc] only.
Lance and I will raise this in our next update (which should be tomorrow) if we don't have a volunteer here.
I was waiting in case anyone shows up for that but looks like no. I can take this goal.
-gmann
JP.
Doug Hellmann wrote:
[...] During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team. Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on docs.openstack.org to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I'm a bit skeptical of that approach.
Proper peer mentoring takes a lot of time, so I expect there will be a limited number of "I'll spend significant time helping you if you help us" offers. I don't envision potential contributors to browse dozens of project-specific "on-boarding doc" to find them. I would rather consolidate those offers on a single page.
So.. either some magic consolidation job that takes input from all of those project-specific repos to build a nice rendered list... Or just a wiki page ?
Thierry Carrez thierry@openstack.org writes:
Doug Hellmann wrote:
[...] During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team. Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on docs.openstack.org to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I'm a bit skeptical of that approach.
Proper peer mentoring takes a lot of time, so I expect there will be a limited number of "I'll spend significant time helping you if you help us" offers. I don't envision potential contributors to browse dozens of project-specific "on-boarding doc" to find them. I would rather consolidate those offers on a single page.
So.. either some magic consolidation job that takes input from all of those project-specific repos to build a nice rendered list... Or just a wiki page ?
-- Thierry Carrez (ttx)
A wiki page would be nicely lightweight, so that approach makes some sense. Maybe if the only maintenance is to review the page periodically, we can convince one of the existing mentorship groups or the first contact SIG to do that.
---- On Thu, 07 Feb 2019 21:42:53 +0900 Doug Hellmann doug@doughellmann.com wrote ----
Thierry Carrez thierry@openstack.org writes:
Doug Hellmann wrote:
[...] During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team. Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on docs.openstack.org to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I'm a bit skeptical of that approach.
Proper peer mentoring takes a lot of time, so I expect there will be a limited number of "I'll spend significant time helping you if you help us" offers. I don't envision potential contributors to browse dozens of project-specific "on-boarding doc" to find them. I would rather consolidate those offers on a single page.
So.. either some magic consolidation job that takes input from all of those project-specific repos to build a nice rendered list... Or just a wiki page ?
-- Thierry Carrez (ttx)
A wiki page would be nicely lightweight, so that approach makes some sense. Maybe if the only maintenance is to review the page periodically, we can convince one of the existing mentorship groups or the first contact SIG to do that.
Same can be achieved If we have a single link on doc.openstack.org or contributor guide with top section "Help-wanted" with subsection of each project specific help-wanted. project help wanted subsection can be build from help wanted section from project contributor doc.
That way it is easy for the project team to maintain their help wanted list. Wiki page can have the challenge of prioritizing and maintain the list.
-gmann
-- Doug
Ghanshyam Mann gmann@ghanshyammann.com writes:
---- On Thu, 07 Feb 2019 21:42:53 +0900 Doug Hellmann doug@doughellmann.com wrote ----
Thierry Carrez thierry@openstack.org writes:
Doug Hellmann wrote:
[...] During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team. Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on docs.openstack.org to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I'm a bit skeptical of that approach.
Proper peer mentoring takes a lot of time, so I expect there will be a limited number of "I'll spend significant time helping you if you help us" offers. I don't envision potential contributors to browse dozens of project-specific "on-boarding doc" to find them. I would rather consolidate those offers on a single page.
So.. either some magic consolidation job that takes input from all of those project-specific repos to build a nice rendered list... Or just a wiki page ?
-- Thierry Carrez (ttx)
A wiki page would be nicely lightweight, so that approach makes some sense. Maybe if the only maintenance is to review the page periodically, we can convince one of the existing mentorship groups or the first contact SIG to do that.
Same can be achieved If we have a single link on doc.openstack.org or contributor guide with top section "Help-wanted" with subsection of each project specific help-wanted. project help wanted subsection can be build from help wanted section from project contributor doc.
That way it is easy for the project team to maintain their help wanted list. Wiki page can have the challenge of prioritizing and maintain the list.
-gmann
-- Doug
Another benefit of using the wiki is that SIGs and pop-up teams can add their own items. We don't have a good way for those groups to be integrated with docs.openstack.org right now.
---- On Fri, 08 Feb 2019 01:07:33 +0900 Doug Hellmann doug@doughellmann.com wrote ----
Ghanshyam Mann gmann@ghanshyammann.com writes:
---- On Thu, 07 Feb 2019 21:42:53 +0900 Doug Hellmann doug@doughellmann.com wrote ----
Thierry Carrez thierry@openstack.org writes:
Doug Hellmann wrote:
[...] During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team. Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on docs.openstack.org to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I'm a bit skeptical of that approach.
Proper peer mentoring takes a lot of time, so I expect there will be a limited number of "I'll spend significant time helping you if you help us" offers. I don't envision potential contributors to browse dozens of project-specific "on-boarding doc" to find them. I would rather consolidate those offers on a single page.
So.. either some magic consolidation job that takes input from all of those project-specific repos to build a nice rendered list... Or just a wiki page ?
-- Thierry Carrez (ttx)
A wiki page would be nicely lightweight, so that approach makes some sense. Maybe if the only maintenance is to review the page periodically, we can convince one of the existing mentorship groups or the first contact SIG to do that.
Same can be achieved If we have a single link on doc.openstack.org or contributor guide with top section "Help-wanted" with subsection of each project specific help-wanted. project help wanted subsection can be build from help wanted section from project contributor doc.
That way it is easy for the project team to maintain their help wanted list. Wiki page can have the challenge of prioritizing and maintain the list.
-gmann
-- Doug
Another benefit of using the wiki is that SIGs and pop-up teams can add their own items. We don't have a good way for those groups to be integrated with docs.openstack.org right now.
Nice point about SIG. pop-up teams are more of volunteer only which might have less chance to make an entry in this list. My main concern with wiki is, it easily ( and maybe most of them ) gets obsolete. Especially in this case where technical ownership is distributed.
-gmann
-- Doug
On Thu, Feb 7, 2019 at 4:45 AM Doug Hellmann doug@doughellmann.com wrote:
Thierry Carrez thierry@openstack.org writes:
Doug Hellmann wrote:
[...] During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team. Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on
docs.openstack.org
to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I'm a bit skeptical of that approach.
Proper peer mentoring takes a lot of time, so I expect there will be a limited number of "I'll spend significant time helping you if you help us" offers. I don't envision potential contributors to browse dozens of project-specific "on-boarding doc" to find them. I would rather consolidate those offers on a single page.
So.. either some magic consolidation job that takes input from all of those project-specific repos to build a nice rendered list... Or just a wiki page ?
-- Thierry Carrez (ttx)
A wiki page would be nicely lightweight, so that approach makes some sense. Maybe if the only maintenance is to review the page periodically, we can convince one of the existing mentorship groups or the first contact SIG to do that.
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.
In my mind I see the help most wanted list as being useful if we want to point people at specific projects that need more hands than others, but I think that the problem is that its hard to quanitfy/keep up to date and the TC was put in charge thinking that they had a better lay of the overall landscape? I think it could go away as documentation maintained by the TC. If we wanted to try to keep a like.. top 5 projects that need friends list... that could live in the FC SIG wiki as well I think.
-- Doug
-Kendall (diablo_rojo)
Kendall Nelson kennelson11@gmail.com writes:
On Thu, Feb 7, 2019 at 4:45 AM Doug Hellmann doug@doughellmann.com wrote:
Thierry Carrez thierry@openstack.org writes:
Doug Hellmann wrote:
[...] During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team. Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on
docs.openstack.org
to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I'm a bit skeptical of that approach.
Proper peer mentoring takes a lot of time, so I expect there will be a limited number of "I'll spend significant time helping you if you help us" offers. I don't envision potential contributors to browse dozens of project-specific "on-boarding doc" to find them. I would rather consolidate those offers on a single page.
So.. either some magic consolidation job that takes input from all of those project-specific repos to build a nice rendered list... Or just a wiki page ?
-- Thierry Carrez (ttx)
A wiki page would be nicely lightweight, so that approach makes some sense. Maybe if the only maintenance is to review the page periodically, we can convince one of the existing mentorship groups or the first contact SIG to do that.
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.
In my mind I see the help most wanted list as being useful if we want to point people at specific projects that need more hands than others, but I think that the problem is that its hard to quanitfy/keep up to date and the TC was put in charge thinking that they had a better lay of the overall landscape? I think it could go away as documentation maintained by the TC. If we wanted to try to keep a like.. top 5 projects that need friends list... that could live in the FC SIG wiki as well I think.
When we started the current list we had a pretty small set of very high priority gaps to fill. The list is growing, the priorities are changes, and the previous list wasn't especially effective. All of which is driving this desire to have a new list of some sort.
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 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.
Maybe the two efforts can converge into one, or they can be kept as two different things but coordinated by the same team ?
On Mon, Feb 11, 2019 at 8:01 AM Thierry Carrez thierry@openstack.org wrote:
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 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?
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).
-- Thierry Carrez (ttx)
-Kendall (diablo_rojo)
Also, to keep everyone on the same page, this topic was discussed in the D&I WG meeting today for those interested[1]. Long story short, the organizers of the mentoring cohort program are concerned that this might take away from their efforts. We talked a little bit about who would be making use of this list, how it should be formatted, how postings enter/exit the list,etc.
-Kendall (diablo_rojo)
[1] http://eavesdrop.openstack.org/meetings/diversity_wg/2019/diversity_wg.2019-...
On Mon, Feb 11, 2019 at 9:14 AM Kendall Nelson kennelson11@gmail.com wrote:
On Mon, Feb 11, 2019 at 8:01 AM Thierry Carrez thierry@openstack.org wrote:
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 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?
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).
-- Thierry Carrez (ttx)
-Kendall (diablo_rojo)
---- 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 thierry@openstack.org wrote: 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 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)
On Tue, Feb 12, 2019 at 12:21 AM Ghanshyam Mann gmann@ghanshyammann.com 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 thierry@openstack.org
wrote:
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
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:
- 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.
I was thinking more yearly than per release if its not too much work for project teams.
I think each item on the list also needs clear completion criteria. If the item hasn't been picked up in like two releases or something we (the FC SIG) can send it back to the project team to make sure its still relevant, the mentor is correct, etc.
- 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)
-Kendall (diablo_rojo)
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
thierry@openstack.org wrote:
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
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:
- 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
On Tue, 12 Feb 2019, Colleen Murphy wrote:
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.
Thank you for writing this message and especially this ^ paragraph. I've been watching this thread with some concern, feeling like the depth of _need_ and _effort_ was being lost. You've captured it well here and I think that this
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.
is right as well. In this instance the imprimatur of the TC is supposed to give weight to the need. As important as the mentorship programs and first contact efforts are, they are for a different kind of thing.
Thank you.
---- 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
thierry@openstack.org wrote:
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
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:
- 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
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.
Well said. I think we need to use another term for this program, to avoid colliding with other forms of mentoring or on-boarding help.
On the #openstack-tc channel, I half-jokingly suggested to call this the 'Padawan' program, but now that I'm sober, I feel like it might actually capture what we are trying to do here:
- Padawans are 1:1 trained by a dedicated, experienced team member - Padawans feel the Force, they just need help and perspective to master it - Padawans ultimately join the team* and may have a padawan of their own - Bonus geek credit for using Star Wars references
* unless they turn to the Dark Side, always a possibility
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.
I think we need a single list. I guess it could be sourced from several repositories, but at least for the start I would not over-engineer it, just put it out there as a replacement for the help-most-needed list and see if it flies.
As a next step, I propose to document the concept on a TC page, then reach out to the currently-listed teams on help-most-wanted to see if there would be a volunteer interested in offering Padawan training and bootstrap the new list, before we start to promote it more actively.
On 2019-02-14 14:29:44 +0100 (+0100), Thierry Carrez wrote:
Well said. I think we need to use another term for this program, to avoid colliding with other forms of mentoring or on-boarding help.
On the #openstack-tc channel, I half-jokingly suggested to call this the 'Padawan' program
[...]
A more traditional Franco-English term for this might be "protoge" or, if you prefer Japanese, perhaps 弟子 (deshi).
Updating the thread since we talked about this quite a bit in the -tc channel, too [0] (sorry for duplicating across communication mediums!)
TL;DR the usefulness of job descriptions is still a thing. To kick start that, I proposed an example to the current help wanted list to kick start what we want our "job descriptions" to look like [1], if we were to have them.
[0] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-... [1] https://review.openstack.org/#/c/637025/
On 2/14/19 7:29 AM, Thierry Carrez wrote:
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.
Well said. I think we need to use another term for this program, to avoid colliding with other forms of mentoring or on-boarding help.
On the #openstack-tc channel, I half-jokingly suggested to call this the 'Padawan' program, but now that I'm sober, I feel like it might actually capture what we are trying to do here:
- Padawans are 1:1 trained by a dedicated, experienced team member
- Padawans feel the Force, they just need help and perspective to
master it
- Padawans ultimately join the team* and may have a padawan of their own
- Bonus geek credit for using Star Wars references
- unless they turn to the Dark Side, always a possibility
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.
I think we need a single list. I guess it could be sourced from several repositories, but at least for the start I would not over-engineer it, just put it out there as a replacement for the help-most-needed list and see if it flies.
As a next step, I propose to document the concept on a TC page, then reach out to the currently-listed teams on help-most-wanted to see if there would be a volunteer interested in offering Padawan training and bootstrap the new list, before we start to promote it more actively.
Having my FC SIG hat on: To summarize about having the 'Help wanted list' under FC SIG, we discussed that in FC meeting this week[1] and planned to have it under TC as first option and if there is no candidate to own it then we re-discuss it to have under FC SIG.
After seeing reply from ttx and IRC chat, it seems we are going to give it another chance under TC. So FC SIG is all ok to help/advertise or direct new contributor to that list or contact owner.
Having my TC hat on: I agree with ttx idea of 1:1 mapping and I feel that is much needed to make it a success. But please choose some simple name so that people do not need to search or have a hard time to understand it :). Help/Mentor/Pending/Volunteer can be very simple word to understand it.
As ttx mentioned about next step, I am listing it in more detail: - Have template to request the items to be added in this list. I prefer it via gerrit and TC review that and approve accordingly. - Add Job Description section also in that list which can vary in term or skill needed per item. lance already started that - https://review.openstack.org/#/c/637025/1 - Clean up the old list and ask for a new list from the community. Or ask old list requester to continue or re-submit the request. - Assign a TC member as Owner to this work.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-mee...
-gmann
---- On Fri, 15 Feb 2019 03:51:19 +0900 Lance Bragstad lbragstad@gmail.com wrote ----
Updating the thread since we talked about this quite a bit in the -tc channel, too [0] (sorry for duplicating across communication mediums!) TL;DR the usefulness of job descriptions is still a thing. To kick start that, I proposed an example to the current help wanted list to kick start what we want our "job descriptions" to look like [1], if we were to have them. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-02-14.log.html#t2019-02-14T16:53:55 [1] https://review.openstack.org/#/c/637025/ On 2/14/19 7:29 AM, Thierry Carrez wrote: 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. Well said. I think we need to use another term for this program, to avoid colliding with other forms of mentoring or on-boarding help. On the #openstack-tc channel, I half-jokingly suggested to call this the 'Padawan' program, but now that I'm sober, I feel like it might actually capture what we are trying to do here: - Padawans are 1:1 trained by a dedicated, experienced team member - Padawans feel the Force, they just need help and perspective to master it - Padawans ultimately join the team* and may have a padawan of their own - Bonus geek credit for using Star Wars references * unless they turn to the Dark Side, always a possibility 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. I think we need a single list. I guess it could be sourced from several repositories, but at least for the start I would not over-engineer it, just put it out there as a replacement for the help-most-needed list and see if it flies. As a next step, I propose to document the concept on a TC page, then reach out to the currently-listed teams on help-most-wanted to see if there would be a volunteer interested in offering Padawan training and bootstrap the new list, before we start to promote it more actively.
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.
On Mon, Feb 4, 2019 at 9:26 AM Doug Hellmann doug@doughellmann.com wrote:
Jeremy Stanley fungi@yuggoth.org writes:
On 2019-02-04 17:31:46 +0900 (+0900), Ghanshyam Mann wrote: [...]
If I recall it correctly from Board+TC meeting, TC is looking for a new home for this list ? Or we continue to maintain this in TC itself which should not be much effort I feel.
[...]
It seems like you might be referring to the in-person TC meeting we held on the Sunday prior to the Stein PTG in Denver (Alan from the OSF BoD was also present). Doug's recap can be found in the old openstack-dev archive here:
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.htm...
Quoting Doug, "...it wasn't clear that the TC was the best group to manage a list of 'roles' or other more detailed information. We discussed placing that information into team documentation or hosting it somewhere outside of the governance repository where more people could contribute." (If memory serves, this was in response to earlier OSF BoD suggestions that retooling the Help Wanted list to be a set of business-case-focused job descriptions might garner more uptake from the organizations they represent.) -- Jeremy Stanley
Right, the feedback was basically that we might have more luck convincing companies to provide resources if we were more specific about how they would be used by describing the work in more detail. When we started thinking about how that change might be implemented, it seemed like managing the information a well-defined job in its own right, and our usual pattern is to establish a group of people interested in doing something and delegating responsibility to them. When we talked about it in the TC meeting in Denver we did not have any TC members volunteer to drive the implementation to the next step by starting to recruit a team.
During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team.
This was something I thought the docs team was working on pushing with all of the individual projects, but I am happy to help if they need extra hands. I think this is suuuuuper important. Each Upstream Institute we teach all the general info we can, but we always mention that there are project specific ways of handling things and project specific processes. If we want to lower the barrier for new contributors, good per project documentation is vital.
Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on docs.openstack.org to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I think maintaining the project liaison list[1] that the First Contact SIG has kind of does this? Between that list and the mentoring cohort program that lives under the D&I WG, I think we have things covered. Its more a matter of publicizing those than starting something new I think?
So, maybe the next step is to convince someone to champion a goal of improving our contributor documentation, and to have them describe what the documentation should include, covering the usual topics like how to actually submit patches as well as suggestions for how to describe areas where help is needed in a project and offers to mentor contributors.
Does anyone want to volunteer to serve as the goal champion for that?
I can probably draft a rough outline of places where I see projects diverge and make a template, but where should we have that live?
/me imagines a template similar to the infra spec template
-- Doug
[1] https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons
Kendall Nelson kennelson11@gmail.com writes:
On Mon, Feb 4, 2019 at 9:26 AM Doug Hellmann doug@doughellmann.com wrote:
Jeremy Stanley fungi@yuggoth.org writes:
On 2019-02-04 17:31:46 +0900 (+0900), Ghanshyam Mann wrote: [...]
If I recall it correctly from Board+TC meeting, TC is looking for a new home for this list ? Or we continue to maintain this in TC itself which should not be much effort I feel.
[...]
It seems like you might be referring to the in-person TC meeting we held on the Sunday prior to the Stein PTG in Denver (Alan from the OSF BoD was also present). Doug's recap can be found in the old openstack-dev archive here:
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.htm...
Quoting Doug, "...it wasn't clear that the TC was the best group to manage a list of 'roles' or other more detailed information. We discussed placing that information into team documentation or hosting it somewhere outside of the governance repository where more people could contribute." (If memory serves, this was in response to earlier OSF BoD suggestions that retooling the Help Wanted list to be a set of business-case-focused job descriptions might garner more uptake from the organizations they represent.) -- Jeremy Stanley
Right, the feedback was basically that we might have more luck convincing companies to provide resources if we were more specific about how they would be used by describing the work in more detail. When we started thinking about how that change might be implemented, it seemed like managing the information a well-defined job in its own right, and our usual pattern is to establish a group of people interested in doing something and delegating responsibility to them. When we talked about it in the TC meeting in Denver we did not have any TC members volunteer to drive the implementation to the next step by starting to recruit a team.
During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team.
This was something I thought the docs team was working on pushing with all of the individual projects, but I am happy to help if they need extra hands. I think this is suuuuuper important. Each Upstream Institute we teach all the general info we can, but we always mention that there are project specific ways of handling things and project specific processes. If we want to lower the barrier for new contributors, good per project documentation is vital.
Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on docs.openstack.org to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I think maintaining the project liaison list[1] that the First Contact SIG has kind of does this? Between that list and the mentoring cohort program that lives under the D&I WG, I think we have things covered. Its more a matter of publicizing those than starting something new I think?
So, maybe the next step is to convince someone to champion a goal of improving our contributor documentation, and to have them describe what the documentation should include, covering the usual topics like how to actually submit patches as well as suggestions for how to describe areas where help is needed in a project and offers to mentor contributors.
Does anyone want to volunteer to serve as the goal champion for that?
I can probably draft a rough outline of places where I see projects diverge and make a template, but where should we have that live?
/me imagines a template similar to the infra spec template
Could we put it in the project team guide?
-- Doug
[1] https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons
Yeah I think the Project Team Guide makes sense.
-Kendall (diablo_rojo)
On Thu, 7 Feb 2019, 12:29 pm Doug Hellmann, doug@doughellmann.com wrote:
Kendall Nelson kennelson11@gmail.com writes:
On Mon, Feb 4, 2019 at 9:26 AM Doug Hellmann doug@doughellmann.com
wrote:
Jeremy Stanley fungi@yuggoth.org writes:
On 2019-02-04 17:31:46 +0900 (+0900), Ghanshyam Mann wrote: [...]
If I recall it correctly from Board+TC meeting, TC is looking for a new home for this list ? Or we continue to maintain this in TC itself which should not be much effort I feel.
[...]
It seems like you might be referring to the in-person TC meeting we held on the Sunday prior to the Stein PTG in Denver (Alan from the OSF BoD was also present). Doug's recap can be found in the old openstack-dev archive here:
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.htm...
Quoting Doug, "...it wasn't clear that the TC was the best group to manage a list of 'roles' or other more detailed information. We discussed placing that information into team documentation or hosting it somewhere outside of the governance repository where more people could contribute." (If memory serves, this was in response to earlier OSF BoD suggestions that retooling the Help Wanted list to be a set of business-case-focused job descriptions might garner more uptake from the organizations they represent.) -- Jeremy Stanley
Right, the feedback was basically that we might have more luck convincing companies to provide resources if we were more specific about how they would be used by describing the work in more detail. When we started thinking about how that change might be implemented, it seemed like managing the information a well-defined job in its own right, and our usual pattern is to establish a group of people interested in doing something and delegating responsibility to them. When we talked about it in the TC meeting in Denver we did not have any TC members volunteer to drive the implementation to the next step by starting to recruit a team.
During the Train series goal discussion in Berlin we talked about having a goal of ensuring that each team had documentation for bringing new contributors onto the team.
This was something I thought the docs team was working on pushing with
all
of the individual projects, but I am happy to help if they need extra hands. I think this is suuuuuper important. Each Upstream Institute we teach all the general info we can, but we always mention that there are project specific ways of handling things and project specific processes.
If
we want to lower the barrier for new contributors, good per project documentation is vital.
Offering specific mentoring resources seems to fit nicely with that goal, and doing it in each team's repository in a consistent way would let us build a central page on
docs.openstack.org
to link to all of the team contributor docs, like we link to the user and installation documentation, without requiring us to find a separate group of people to manage the information across the entire community.
I think maintaining the project liaison list[1] that the First Contact
SIG
has kind of does this? Between that list and the mentoring cohort program that lives under the D&I WG, I think we have things covered. Its more a matter of publicizing those than starting something new I think?
So, maybe the next step is to convince someone to champion a goal of improving our contributor documentation, and to have them describe what the documentation should include, covering the usual topics like how to actually submit patches as well as suggestions for how to describe areas where help is needed in a project and offers to mentor contributors.
Does anyone want to volunteer to serve as the goal champion for that?
I can probably draft a rough outline of places where I see projects
diverge
and make a template, but where should we have that live?
/me imagines a template similar to the infra spec template
Could we put it in the project team guide?
-- Doug
[1] https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons
-- Doug
participants (13)
-
Chris Dent
-
Colleen Murphy
-
Doug Hellmann
-
Ghanshyam Mann
-
Jean-Philippe Evrard
-
Jeremy Stanley
-
Jill Rouleau
-
Kendall Nelson
-
Lance Bragstad
-
Lingxian Kong
-
Sean Mooney
-
Thierry Carrez
-
Zane Bitter