Yeah I think the Project Team Guide makes sense. <br><br>-Kendall (diablo_rojo)<div><br><div dir="auto"><div dir="auto"><div class="gmail_quote"><div dir="ltr">On Thu, 7 Feb 2019, 12:29 pm Doug Hellmann, <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kendall Nelson <<a href="mailto:kennelson11@gmail.com" target="_blank">kennelson11@gmail.com</a>> writes:<br>
<br>
> On Mon, Feb 4, 2019 at 9:26 AM Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>> wrote:<br>
><br>
>> Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> writes:<br>
>><br>
>> > On 2019-02-04 17:31:46 +0900 (+0900), Ghanshyam Mann wrote:<br>
>> > [...]<br>
>> >> If I recall it correctly from  Board+TC meeting, TC is looking for<br>
>> >> a new home for this list ? Or we continue to maintain this in TC<br>
>> >> itself which should not be much effort I feel.<br>
>> > [...]<br>
>> ><br>
>> > It seems like you might be referring to the in-person TC meeting we<br>
>> > held on the Sunday prior to the Stein PTG in Denver (Alan from the<br>
>> > OSF BoD was also present). Doug's recap can be found in the old<br>
>> > openstack-dev archive here:<br>
>> ><br>
>> ><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.html</a><br>
>> ><br>
>> > Quoting Doug, "...it wasn't clear that the TC was the best group to<br>
>> > manage a list of 'roles' or other more detailed information. We<br>
>> > discussed placing that information into team documentation or<br>
>> > hosting it somewhere outside of the governance repository where more<br>
>> > people could contribute." (If memory serves, this was in response to<br>
>> > earlier OSF BoD suggestions that retooling the Help Wanted list to<br>
>> > be a set of business-case-focused job descriptions might garner more<br>
>> > uptake from the organizations they represent.)<br>
>> > --<br>
>> > Jeremy Stanley<br>
>><br>
>> Right, the feedback was basically that we might have more luck<br>
>> convincing companies to provide resources if we were more specific about<br>
>> how they would be used by describing the work in more detail. When we<br>
>> started thinking about how that change might be implemented, it seemed<br>
>> like managing the information a well-defined job in its own right, and<br>
>> our usual pattern is to establish a group of people interested in doing<br>
>> something and delegating responsibility to them. When we talked about it<br>
>> in the TC meeting in Denver we did not have any TC members volunteer to<br>
>> drive the implementation to the next step by starting to recruit a team.<br>
>><br>
>> During the Train series goal discussion in Berlin we talked about having<br>
>> a goal of ensuring that each team had documentation for bringing new<br>
>> contributors onto the team.<br>
><br>
><br>
> This was something I thought the docs team was working on pushing with all<br>
> of the individual projects, but I am happy to help if they need extra<br>
> hands. I think this is suuuuuper important. Each Upstream Institute we<br>
> teach all the general info we can, but we always mention that there are<br>
> project specific ways of handling things and project specific processes. If<br>
> we want to lower the barrier for new contributors, good per project<br>
> documentation is vital.<br>
><br>
><br>
>> Offering specific mentoring resources seems<br>
>> to fit nicely with that goal, and doing it in each team's repository in<br>
>> a consistent way would let us build a central page on <a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a><br>
>> to link to all of the team contributor docs, like we link to the user<br>
>> and installation documentation, without requiring us to find a separate<br>
>> group of people to manage the information across the entire community.<br>
><br>
><br>
> I think maintaining the project liaison list[1] that the First Contact SIG<br>
> has kind of does this? Between that list and the mentoring cohort program<br>
> that lives under the D&I WG, I think we have things covered. Its more a<br>
> matter of publicizing those than starting something new I think?<br>
><br>
><br>
>><br>
>> So, maybe the next step is to convince someone to champion a goal of<br>
>> improving our contributor documentation, and to have them describe what<br>
>> the documentation should include, covering the usual topics like how to<br>
>> actually submit patches as well as suggestions for how to describe areas<br>
>> where help is needed in a project and offers to mentor contributors.<br>
><br>
>> Does anyone want to volunteer to serve as the goal champion for that?<br>
>><br>
>><br>
> I can probably draft a rough outline of places where I see projects diverge<br>
> and make a template, but where should we have that live?<br>
><br>
> /me imagines a template similar to the infra spec template<br>
<br>
Could we put it in the project team guide?<br>
<br>
><br>
><br>
>> --<br>
>> Doug<br>
>><br>
>><br>
>  [1] <a href="https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons</a><br>
<br>
-- <br>
Doug<br>
</blockquote></div></div></div></div>