[openstack-dev] [all][stackalytics] Gaming the Stackalytics stats
Adam Lawson
alawson at aqorn.com
Sat Apr 9 21:19:39 UTC 2016
I have a quick question:
How is anyone hurt out harmed by the practice? I agree it isn't helpful.
But it isn't harming either. It could be gaming and it could be ignorance -
mistakes by not knowing.
I'm asking because I see the same predictable personalities making passive
aggressive accusations against their peers about gaming and ill intent.
When folks are approached, they realize it is due to not knowing. Their
answers are received with suspicion and presumptions that they are in the
minority.
We really need to stop rushing to embrace the worst in each other.
//adam
On Apr 9, 2016 1:18 PM, "Morgan Fainberg" <morgan.fainberg at gmail.com> wrote:
On Apr 9, 2016 12:05, "Ken'ichi Ohmichi" <ken1ohmichi at gmail.com> wrote:
>
>
> 2016/04/08 10:55、Anita Kuno <anteaya at anteaya.info> :
>
> >> On 04/08/2016 01:42 PM, Dmitry Tantsur wrote:
> >> 2016-04-08 19:26 GMT+02:00 Davanum Srinivas <davanum at gmail.com>:
> >>
> >>> Team,
> >>>
> >>> Steve pointed out to a problem in Stackalytics:
> >>> https://twitter.com/stevebot/status/718185667709267969
> >>
> >>
> >> There are many ways to game a simple +1 counter, such as +1'ing changes
> >> that already have at least 1x +2, or which already approved, or which
need
> >> rechecking...
>
> Can we merge this kind of patches without reviews?
> When seeing this kind of patches, I check all jobs are succeeded.
Sometimes some job failed, I check the reason and +2 if that is unrelated.
>
> This workflow seems possible to be implemented automatically.
> Or bad idea?
>
> Thanks
>
A true automerge has potential to accidentally clobber things in an ugly
way if it goes wrong. The auto propose but core approval still has a level
of human spot checking. I would personally be uncomfortable with the bot
automatically merging things. At face value the overhead of a core
approval and possibility of what is highlighted in this thread is better
IMHO.
>
>
>
>
>
>
>
> >>
> >>
> >>>
> >>>
> >>> 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?
> >>
> >> One more possible (though also imperfect) mitigation is to make
exception
> >> from the usual 2x +2 rule for requirements updates passing gates and
use
> >> only 1x +2. Then requirements reviews will take substantially less
time to
> >> land, reducing need/possibility of having such +1's.
> >
> > Proposal bot patches merge in many cases with 1 +2 already.
> >
> > Have you looked at the timing of the bot patches generated and the first
> > +1's? If not, take a look at that.
> >
> > I don't think we should be expecting core reviewers to schedule
> > approving bot proposals to prevent extraneous +1s.
> >
> > Thanks,
> > Anita.
> >
> >>
> >>>
> >>> Thanks,
> >>> Dims
> >>>
> >>> --
> >>> Davanum Srinivas :: https://twitter.com/dims
> >>>
> >>>
__________________________________________________________________________
> >>> 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
> >
> >
> >
__________________________________________________________________________
> > 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
__________________________________________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160409/72fd1819/attachment.html>
More information about the OpenStack-dev
mailing list