Excerpts from Ildiko Vancsa's message of 2017-09-22 13:20:31 -0600: > Hi All, > > Another forum we try to put emphasis on this is the Upstream Institute > trainings we have before the Summits and on some smaller events as well. > > We usually try to spend some quality time on review best practices and on > metrics as well. The aim is to make people realize that if they need practice > with the process the project repositories are not the place for that and also > to let them know that we see the patterns and they get negative recognition > for it. > > The only issue with that is I’m not sure we always have the right audience, > like people might not contribute after all neither they give the knowledge > and heads up to their colleagues in the company who do. :( Regardless of this > we will continue to highlight these and if you have suggestion on what else > we should mention or how to better articulate it we are open to ideas. > > We were also thinking about collecting ideas and suggestions for people who > would take on mentoring in projects, like what and how to do. Do you see this > activity being part of that too? Could we say something like if we have a few > people per project who are willing to coach and mentor people we can have a > small set of guidelines for them on how to start the communication for these > cases? Or would this rather be handled centrally? > > As for those who are practicing we have sandbox repositories/projects in all > the tools which might worth highlighting. > > The new Contributor Portal can also be a good place to highlight > corresponding best practices and point out behaviors we disagree with.
It makes sense to repeat this information in a few places, with references to an extensive explanation in the project team guide. I don't think that would have helped in the current cases, but it won't hurt in the future. Doug > > Thanks, > Ildikó > IRC: ildikov > > > On 2017. Sep 22., at 12:47, Doug Hellmann <d...@doughellmann.com> wrote: > > > > Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06 > > -0400: > >> Doug, > >> Howard (cc'ed) already did a bunch of reaching out especially on > >> wechat. We should request his help. > >> > >> Howard, > >> Can you please help with communications and follow up? > >> > >> Thanks, > >> Dims > > > > Thanks, Dims and Howard, > > > > I think the problem has reached a point where it would be a good > > idea to formalize our approach to outreach. We should track the > > patches or patch series identified as problematic, so reviewers > > know not to bother with them. We can also track who is contacting > > whom (and how) so we don't have a bunch of people replicating work > > or causing confusion for people who are trying to contribute. Having > > that information will also help us figure out when we need to > > escalate by finding the right managers to be talking to. > > > > Let's put together a small team to manage this instead of letting > > it continue to cause frustration for everyone. > > > > Doug > > > >> > >> On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann <d...@doughellmann.com> > >> wrote: > >>> Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500: > >>>> On 9/22/2017 7:10 AM, Tom Barron wrote: > >>>>> FWIW I think it is better not to attribute motivation in these cases. > >>>>> Perhaps the code submitter is trying to pad stats, but perhaps they are > >>>>> just a new contributor trying to learn the process with a "harmless" > >>>>> patch, or just a compulsive clean-upper who hasn't thought through the > >>>>> costs in reviewer time and CI resources. > >>>> > >>>> I agree. However, the one that set me off last night was a person from > >>>> one company who I've repeatedly -1ed the same types of patches in nova > >>>> for weeks, including on stable branches, and within 10 minutes of each > >>>> other across several repos, so it's clearly part of some daily routine. > >>>> That's what prompted me to send something to the mailing list. > >>>> > >>> > >>> As fungi points out, education and communication are likely to be > >>> our best solution. Maybe one approach is to identify the companies > >>> and individuals involved and find one of our community members to > >>> contact them directly via email. We would want the person doing > >>> that to be willing to explain all of the reasons the community does > >>> not want the sort of activity we are rejecting and to provide > >>> guidance about more useful contributions (Matt's comment is a great > >>> start on both). I imagine that conversation would take a good deal > >>> of patience, especially after the second or third time, but a personal > >>> touch frequently makes all the difference in these sorts of cases. > >>> > >>> If we have someone willing to step into that sort of role, I would > >>> be happy to help craft the initial contact messages and advise as > >>> needed. > >>> > >>> Does anyone want to volunteer to work with me and actually send the > >>> emails? > >>> > >>> Doug > >>> > >>> __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
