Kamil,

I wasn't intending the time we would get together each week for voting, instead for time spent discussing and clarifying any discrepancies we may have with the bugs. By the time we would have this 30 or so minute get-together, our votes would already be cast in Pagure. We would make sure we were all on the same page, and then use the meeting time to mark the bugs as "Accepted ________".

I like the idea of somehow merging the live meetings with the asynchronous process. Personally, I think the meeting I'm describing should be solely purposed as the "Acceptance/Denial Meeting", where the point is to review the votes in Pagure, and then manually accept/deny the position. That way, we spend a small portion of time on each bug, not voting, but reviewing the votes that should have been already cast. And, if any questions arise regarding a particular bug, we have a platform in which to have a real-time conversation with our peers.

Geoff Marr

IRC: coremodule

On Tue, Dec 3, 2019 at 5:38 AM Kamil Paral <kparal@redhat.com> wrote:

On Mon, Dec 2, 2019 at 11:47 PM Geoffrey Marr <gmarr@redhat.com> wrote:
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)

Hey Geoff. I'm afraid time limits wouldn't work well for us here. I wouldn't want to poorly decide a blocker status just because we were running out of time. In case of our IRC meeting, we also don't accept/reject something just because we're out of time. If that happens, we postpone it until the next meeting, or if we don't have the luxury of one more week, we schedule an exceptional meeting the very next day.

I wonder if we could merge the live+async approaches to get the best of both. What if we handled simple/standard issues fully in tickets, and for complex issues which are difficult to understand and debug, or which have some heated discussions, we'd schedule an IRC meeting and resolve them there? We can either schedule the meetings ad-hoc, or we can use a special tag in Pagure, and the regular Monday blocker review meeting would only occur if there was at least a single open ticket marked with this tag. Does that sound better in your opinion?

_______________________________________________
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