Kamil,
Thanks for working on this. I am glad we are considering something different here, as the current process is not perfect.
Personally, of the suggested options, I think that using Pagure is my preferred option. I think of the available options, it allows for the easiest collaboration between folks who are contemplating and voting on the bugs.
However, I do resonate with some of what Ben said, specifically regarding losing the "live" setting when we vote. The ability to hash things out over IRC real-time is pretty valuable, and to use a different system where time between comments could become large, I wonder if still having a meeting every Monday would be advantageous. Something to go over the votes that have been made on the Pagure page (or whatever system it ends up being). The problem with that is keeping it from turning right back into the old "blocker-review-meeting". We could possibly institute a 30(?) minute time limit, where we go over the bugs to ensure we understand them and then accept the vote right there. That way we have the opportunity to ask questions/clarifications that might be tedious and take a lot of time over a forum-style messaging app. Again, there would have to be some kind of watchdog to prevent us from turning these meetings into what we have now. All this said, should this IRC meeting idea come to fruition, I would be more than happy to coordinate and run these, should anyone else not want to (adamw! :P)
Geoff Marr IRC: coremodule
On Mon, Dec 2, 2019 at 8:02 AM Ben Cotton bcotton@redhat.com wrote:
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@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org 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@lists.fedoraproject.org