On Mon, Dec 2, 2019 at 4:02 PM 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.

Yes, that is true. And perhaps if I had the meetings in the afternoon as you do, instead of late evening when I'd rather be with my family, I wouldn't mind them either :-) Alas, it's not the case, and I'd certainly like to test using tickets. I think having an experiment here is very valuable, we might realize a lot of up&downs as we go, which we don't think about atm.

For example, I believe that one of the most important advantages of async discussion is the ability to better gather developer feedback. Currently, it's very rare that we can contact the developer and gets some responses during our live meeting. But this is exactly what only experience can tell, whether the improvement will be substantial, or whether developers will ignore our tickets and we will be in the same state as we were.

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.

Well, the idea was that a bot keeps count of all the votes and updates a summary. That will not be available from day 1, most probably. But once implemented, that should address this concern, correct?

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".

The current in-Bugzilla process is used just when we need a very fast decision, and I agree it's not ideal. The same approach can be used in tickets (we can say "there are only 3 hours to collect votes, please respond asap"). But we can also be much more flexible. If the QA person in charge (or however you want to name Adam:-)) decides that most of the usual suspects have already voted, he can close the vote. Or he can wait some more, call for more votes, etc. Unlike "in-BZ discussions", these tickets should be much easier to read and manage, you can easily see how old the ticket is, and decide how long you want to wait or if it was enough. And we'll probably have some recommended practices, e.g. unless we're in a rush, wait 2-3 days for votes.

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.

Thanks for your feedback!

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.

This is interesting. I believed that this is just us trying to bend Pagure a little to something it wasn't designed for. But if other groups could benefit from this functionality as well, perhaps we could look at how difficult it would be to implement voting natively in Pagure (and I might hate myself in the future for saying this out loud:)).