On Mon, Dec 2, 2019 at 4:02 PM Ben Cotton <bcot...@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:)).
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
