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: coremoduleOn Mon, Dec 2, 2019 at 8:02 AM Ben Cotton <bcotton@xxxxxxxxxx> 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@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
_______________________________________________ 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
