Open Stack

If this is the bug that triggered this discussion, yes, please never do
anything like that -
https://bugs.launchpad.net/python-openstacksdk/+bug/1475722

The bug now has too many projects to take any actions on it.

I think a basic rule of thumb that before creating a bug that has > 4
projects on it, make sure that you've socialized that idea on the
mailing list. Work that actually cuts across that many projects really
is going to need a community discussion to figure out where it phases
things in.

On 09/21/2016 08:15 AM, gordon chung wrote:
> i feel like this gets brought up every year. we block these patches in 
> Telemetry projects unless they can be justified beyond the copy/paste 
> description.
> 
> in addition to this, please, PLEASE stop creating 'all project bugs'. i 
> don't want to get emails on updates to projects unrelated to the ones i 
> care about. also, it makes updating the bug impossible because it times 
> out. i'm too lazy to search ML but this has been raise before, please stop.
> 
> let's all unite together and block these patches to bring an end to it. :)
> 
> On 21/09/16 07:56 AM, Amrith Kumar wrote:
>> Of late I've been seeing a lot of rather questionable changes that
>> appear to be getting blasted out across multiple projects; changes that
>> cause considerable code churn, and don't (IMHO) materially improve the
>> quality of OpenStack.
>>
>> I’d love to provide a list of the changes that triggered this email but
>> I know that this will result in a rat hole where we end up discussing
>> the merits of the individual items on the list and lose sight of the
>> bigger picture. That won’t help address the question I have below in any
>> way, so I’m at a disadvantage of having to describe my issue in abstract
>> terms.
>>
>>
>>
>> Here’s how I characterize these changes (changes that meet one or more
>> of these criteria):
>>
>>
>>
>> -    Contains little of no information in the commit message (often just
>> a single line)
>>
>> -    Makes some generic statement like “Do X not Y”, “Don’t use Z”,
>> “Make ABC better” with no further supporting information
>>
>> -    Fail (literally) every single CI job, clearly never tested by the
>> developer
>>
>> -    Gets blasted across many projects, literally tens with often the
>> same kind of questionable (often wrong) change
>>
>> -    Makes a stylistic python improvement that is not enforced by any
>> check (causes a cottage industry of changes making the same correction
>> every couple of months)
>>
>> -    Reverses some previous python stylistic improvement with no clear
>> reason (another cottage industry)
>>
>>
>>
>> I’ve tried to explain it to myself as enthusiasm, and a desire to
>> contribute aggressively; I’ve lapsed into cynicism at times and tried to
>> explain it as gaming the numbers system, but all that is merely
>> rationalization and doesn’t help.
>>
>>
>>
>> Over time, the result generally is that these developers’ changes get
>> ignored. And that’s not a good thing for the community as a whole. We
>> want to be a welcoming community and one which values all contributions
>> so I’m looking for some suggestions and guidance on how one can work
>> with contributors to try and improve the quality of these changes, and
>> help the contributor feel that their changes are valued by the project?
>> Other more experienced PTL’s, ex-PTL’s, long time open-source-community
>> folks, I’m seriously looking for suggestions and ideas.
>>
>>
>>
>> Any and all input is welcome, do other projects see this, how do you
>> handle it, is this normal, …
>>
>>
>>
>> Thanks!
>>
>>
>>
>> -amrith
>>
> 
> cheers,
> 


-- 
Sean Dague
http://dague.net