Hi, Steve, thanks for pointing that out and Dims, thanks for starting the discussion.
I guess I feel that the drastic step is/may not be necessary. Here's the reason why: we're trying to solve a subjective problem with a objective solution. All systems have loopholes and there will be people who will try to take advantage of them, so we should into look into more contextual info while forming opinions. To say this in more "in practice terms" we are disallowing counting stats for certain specific events, although there could be significant number of those +1s that do matter. An extreme case of this being, a downstream openstack consumer/cloud operator appointing someone to take a look at the ongoing efforts upstream on the requirements and packages; report back on some of the 'internally beware' changes. It would be a loss for the management to track info on such individuals. To lesser extreme, if I've to ask someone to take another look at requirements changes and make sure that the project changes are appropriate that potentially conflict with the updates, such individuals might be demotivated to pick such jobs -- specifically stable and release liaisons, sometime cross project efforts. I think we need to value such work and give a way to (first) the individuals to keep themselves motivated and then management to keep a check. Hence, this is a subjective problem, it applies to some cases and doesn't to others; the info is valuable to have but needs to be consumed correctly. On top of that, I think a general rule of statistics is that -- the more info/large sample set you have, more accurate are the results. How and where you need to read them is we should solve. And I think there are a few today who avoid such speculative results, for ex. quarterly results at your resp. orgs, aren't you interested, do they always tell story of the value addition/subtraction by the org as a whole? Yet they are important, to keep us moving and keep us motivated! Hence, my proposal is: * instead of completely ignoring the stats on such reviews, we either ignore or not ignore them on "generic" +1s * introduce a new more-info-like tab/UI-stuff in Stackalytics and keep those stats there, consequently we need to modify the Stackalytics processor to show that info there * encourage the teams to carefully read the review stats, say % of - vs. + and be more subjective on the evaluation by browsing some of the reviews (TBH, I know that +0s are sometimes the best feedback on reviews). I think this is a bit easier for me to say because I'm primarily looking from Glance perspective which is a relatively small team and we happen to stumble upon each others' reviews often. In the interest of keeping the community inclusive, collaborative and healthy, yours sincerely, On 4/8/16 1:26 PM, Davanum Srinivas wrote: > Team, > > Steve pointed out to a problem in Stackalytics: > https://twitter.com/stevebot/status/718185667709267969 > > It's pretty clear what's happening if you look here: > https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open > > Here's the drastic step (i'd like to avoid): > https://review.openstack.org/#/c/303545/ > > What do you think? > > Thanks, > Dims > > > -- Thanks, Nikhil __________________________________________________________________________ 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
