---- On Tue, 01 Oct 2019 11:19:44 -0500 Balázs Gibizer balazs.gibizer@est.tech wrote ----
On Tue, Oct 1, 2019 at 5:00 PM, Eric Fried openstack@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