Open Stack

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.

Thanks,
Ildikó
IRC: ildikov


> On 2017. Sep 22., at 12:47, Doug Hellmann <doug at 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 <doug at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev