Re: Proposal: Asynchronous blocker review process (using Pagure)

[Kamil Paral <kparal@xxxxxxxxxx>]

On Thu, Nov 28, 2019 at 11:29 PM Frantisek Zatloukal <fzatlouk@xxxxxxxxxx> wrote:

On Thu, Nov 28, 2019 at 1:31 PM Kamil Paral <kparal@xxxxxxxxxx> wrote:

5. Once some kind of understanding of the issue is formed, a privileged member (e.g. a member of @fedora-qa FAS group) can start the vote by including a command in his comment, e.g. "START VOTE" on a separate line. (Note that this is just a proposal. We can easily let anyone start the vote, or we can allow voting right from the 
9. If new important information appear or the vote needs to be repeated for any other reason, a privileged member can restart the vote e.g. by issuing RESTART VOTE command. (We can have more such administrative commands for any purpose we need, same as we have them with IRC bots).

It's probably just a small detail, why would we need (RE)START VOTE commands? It seems we can vote whatever/whenever we want, bot would just count the last VOTE +/- 1, 0 comment (or rather command) from each participant. 

That's a good question. The START VOTE is optional and really up to us if we want to use it. I included it because it seemed to me to mirror what we do during IRC meetings - first we discuss the issue and come to an understanding of the problem, and then people vote (usually). But it's true that for clear-cut issues, people might want to vote immediately. And waiting for a privileged person to start voting every time could prove annoying. So after some consideration, I agree that it might be better to allow people voting right from the beginning.

The RESTART VOTE is useful, though. Imagine a situation where several people voted but then the developer added a comment that the bug might in some cases wipe all user data (or the whole disk). There might be such a bump in severity of the issue, that a QA person might force the vote to be restarted. This makes sure that old votes won't be counted in by accident, and if you look at the vote summary, you can be certain that all the votes displayed were cast by people who were already aware of the increased gravity of the issue.

One more note: During IRC meetings the chair usually posts "proposed #agreed statement" and people ack it or nack it, then it changes to "#agreed statement". I think that won't be possible with ticket meetings, because that would require one additional roundtrip of votes (which might take up to 1 day due to timezones). So I think the workflow will be for people to vote +1/0/-1, and then the selected QA person will simply summarize it into AGREED <RESOLUTION>, and we will trust he/she will do the right thing and also formulate the justification well (of course, if people disagree, the ticket can always be reopened). For contentious issues where there are numerous +1's and -1's, we'll need to deal with it as usual - either punt it, or ask the minority if they're fine with using the majority decision (and then use the AGREED command).

_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx