I want to speak up in defense of synchronous meetings. I acknowledge that the timing is rather convenient for me personally (it's 12–3pm my time), which makes it easier for me to see the upsides. The big benefit is the high bandwidth discussion. I have been in plenty of meetings where someone initially feels one way and has their mind changed over the course of the discussion. This is still possible with asynchronous communication, but it's much more difficult. We generally end up at a pretty good consensus on blocker status, even if it sometimes take two (or three!) meetings. I foresee more +4/0/-3 type votes with an asynchronous method. Relatedly, any asynchronous voting mechanism must make it very easy to know when someone has updated their vote. This is addressed some in the thread, but any async method that requires coremodule (the forever secretary!) to read through each comment to make sure no one changed their mind is inflicting unnecessary pain. IRC has the same problem, but because the time scale is shorter, it makes it easier to see IMO. Synchronous meetings give the voting period a defined end and makes the process quick. If we do it asynchronously, there has to be some deadline that allows people time to vote. Currently, the process is (IIRC) if three people +1 in the BZ, it's counted as accepted. This means a bug could potentially be accepted within minutes, denying those who disagree the opportunity to raise their objections. Of course, we don't want to set the deadline too long because then we have a week of "yeah, it looks like this is a blocker, but also we can't apply the label yet". None of the above should be taken as me saying that the current process is perfect. Nor should it be an objection to the idea of an asynchronous process in principle. I just want to make sure we're intentional about what we're giving up in order to get the benefits of an async process. For what it's worth, voting support in Pagure (or another similar system) would be helpful for many teams within Fedora, including Council, FESCo, and Mindshare who routinely vote on things in tickets. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ 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
