Open Stack

Tony-

Thanks for following up on this!

> The general idea is that the bot would:
>  1. Leave a -1 review on 'qualifying'[2] changes along with a request for
>     some small change

As I mentioned in the room, to give a realistic experience the bot
should wait two or three weeks before tendering its -1.

I kid (in case that wasn't clear).

>  2. Upon seeing a new patchset to the change vote +2 (and possibly +W?)
>     on the change

If you're compiling a list of eventual features for the bot, another one
that could be neat is, after the second patch set, the bot merges a
change that creates a merge conflict on the student's patch, which they
then have to go resolve.

Also, cross-referencing [1], it might be nice to update that tutorial at
some point to use the sandbox repo instead of nova. That could be done
once we have bot action so said action could be incorporated into the
tutorial flow.

> [2] The details of what counts as qualifying can be fleshed out later
>     but there needs to be something so that contributors using the
>     sandbox that don't want to be bothered by the bot wont be.

Yeah, I had been assuming it would be some tag in the commit message. If
we ultimately enact different flows of varying complexity, the tag
syntax could be enriched so students in different courses/grades could
get different experiences. For example:

 Bot-Reviewer: <name-of-osi-course>

or

 Bot-Reviewer: Level 2

or

 Bot-Reviewer: initial-downvote, merge-conflict, series-depth=3

The possibilities are endless :P

-efried

[1] https://review.openstack.org/#/c/634333/