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/