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.
On Tue, Dec 3, 2019 at 5:38 AM Kamil Paral <kparal(a)redhat.com> wrote:
On Mon, Dec 2, 2019 at 11:47 PM Geoffrey Marr
> 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
> 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
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines