Open Stack

---- On Tue, 01 Oct 2019 11:19:44 -0500 Balázs Gibizer <balazs.gibizer at est.tech> wrote ----
 > 
 > 
 > On Tue, Oct 1, 2019 at 5:00 PM, Eric Fried <openstack at fried.cc> wrote:
 > > Thanks for the responses, all.
 > > 
 > > This subthread is becoming tangential to my original purpose, so I'm
 > > renaming it.
>> (A) Constrain scope, drastically. We marked 25 blueprints complete in
>> Train [3]. Since there has been no change to the core team, let's limit
>> Ussuri to 25 blueprints [4]. If this turns out to be too few, what's the
>> worst thing that happens? We finish everything, early, and wish we had
>> do ne more. If that happens, drinks are on me, and we can bump the number
>> for V.

I like the idea here and be more practical than theoretical ways to handle such situation especially in Nova case.
If the operator complains about less accepted BP then, we can ask them to invest developers in upstream which can
avoid such cap. 

But my question is same as gibi, what will be the selection criteria (when we have a large number of ready specs)? 


>> (B) Require a core to commit to "caring about" a spec before we approve
>> it. The point of this "core liaison" is to act as a mentor to mitigate
>> the cultural issues noted above [5], and to be a first point of contact
>> for reviews. I've proposed this to the spec template here [6].

+100 for this. I am sure this way we can burn more approved BP. 

-gmann

 > > 
 > >>>  The best way to get reviews is to lurk in IRC and beg.
 > > <snip>
 > >>  When I joined I was taught that instead of begging go and review 
 > >> open
 > >>  patches which a) helps the review load of dev team b) makes you 
 > >> known
 > >>  in the community. Both helps getting reviews on your patches. Does 
 > >> it
 > >>  always work? No. Do I like begging for review? No. Do I like to get
 > >>  repatedly pinged to review? No. So I would suggest not to declare 
 > >> that
 > >>  the only way to get review is to go and beg.
 > > 
 > > I recognize I was generalizing; begging isn't really "the best way" to
 > > get reviews. Doing reviews and becoming known (and *then* begging :) 
 > > is
 > > far more effective -- but is literally impossible for many 
 > > contributors.
 > > Even if they have the time (percentage of work week) to dedicate
 > > upstream, it takes massive effort and time (calendar) to get there. We
 > > can not and should not expect this of every contributor.
 > > 
 > 
 > Sure, it is not easy for a new commer to read a random nova patch. But 
 > I think we should encourage them to do so. As that is one of the way 
 > how a newcomer will learn how nova (as software) works. I don't expect 
 > from a newcommer to point out in a nova review that I made a mistake 
 > about an obscure nova specific construct. But I think a newcommer still 
 > can give us valuable feedback about the code readability, about generic 
 > python usage, about English grammar...
 > 
 > gibi
 > 
 > 
 >