On Thu, Nov 12, 2020 at 4:15 PM Kamil Paral <kparal@xxxxxxxxxx> wrote:
First, a ticket creation should automatically send a comment to Bugzilla, so that the developer/package maintainer and anyone watching knows about the discussion and can participate (we're fairly bad about it at the moment).
And it would also be nice to reduce the amount of manual secretarialization needed after a vote is accepted - Bugzilla could be ideally updated automatically with the correct flags.
On Thu, Nov 12, 2020 at 6:00 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
* No synchronization of "decision made" between ticket and Bugzilla,
when a decision is made someone has to update both separately (using
different Magic Texts, which it's easy to mess up). It would be really
nice if we could just mark the decision in Bugzilla and have that
automatically propagate to the ticket system.
Please discuss the implementation in https://pagure.io/fedora-qa/blockerbugs/issue/149
* Using Magic Text for voting and admin is awkward and error-prone.
Better UI for this would be really helpful.
I'm not sure how it can be improved. Do you have any ideas?
In addition, the state isn't automatically updated when you vote or mark a decision, so I
always find myself manually refreshing the page after doing it just to
make sure I did it right and the change took effect.
Yes, that's the recommended approach documented at https://pagure.io/fedora-qa/blocker-review . Pagure can actually detect a change in description and in theory it should refresh it live, but mostly I've seen it simply becoming a mess of characters, because while it updated the contents, it didn't render it as RST and it was just a messy output. I wanted to file a bug about it, but when I tested it today, it didn't even respond to description updates and simply nothing happened and I had to reload the page. So I'm not sure whether it's a race or they fixed the previous incorrect behavior by simply not responding to that event, *shrug*. Since Fedora seems to be moving towards Gitlab, I don't want to spend too much time debugging Pagure issues at the moment.
With Lukas Brabec we also considered adding a "thumbs up" reaction to your comment if it contains a well-parsed command, which could show up immediately. But it seems to be not supported by Pagure API at the moment.
Do you have some idea how to make the voting process feedback better, without relying on Pagure bugfixes/feature updates?
* It'd be really nice if the web UI showed the current vote counts from
the ticket. I frequently find myself opening every proposal ticket in a
tab and going through them all just to see if any have enough votes for
a decision yet; it'd be much more efficient if I could just see the
totals at a glance on the blockerbugs web UI overview.
On Thu, Nov 12, 2020 at 9:25 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
I often had to click the 'how to vote' link in a separate tab to copy/paste the proper tag. It'd be nice if the list of possible voting tags is simply incorporated into the initial issue text.
Do you mean the list of trackers - BetaBlocker, FinalBlocker, BetaFE, FinalFE, 0Day, PreviousRelease? I found them quite easy to remember, once you vote in a few tickets. But we can surely include them in every ticket description, along with the link to the full documentation. I just want to make sure I understand you. Or do you mean something different?
On Thu, Nov 12, 2020 at 11:41 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
Sometimes the ticket titles were not very informative, but thats more
the fault of the bug really.
Well, we can easily add e.g. the component the bug was proposed against at the time of the ticket creation. That would add a bit more context. I wanted to keep the ticket title and contents pretty light, because we don't have any infrastructure set up to keep the data synchronized. So if the bug title changes, we don't update it. The same would apply for the component, or release version, currently proposed blockers, etc. And my worry is that it might easily become confusing, if we show a lot of outdated information. We improved that situation at least a little by showing inline images in the ticket description that poll blockerbugs app and show whether the bug is open or closed and which trackers it has already been accepted/rejected with (unfortunately that image loads very slow due to https://pagure.io/pagure/issue/5012 ).
We could add plumbing to update the mentioned data, but it's a lot of work and I'm concerned about reliability. The envision workflow was that you visit the ticket through blockerbugs web app, and so you already know most of the metadata from there. Of course if you sign up for new ticket notifications on the project itself, that's not the case, you're visiting the ticket directly. I'm just not sure if the cost/benefit ratio is good here for mirroring the data inside the ticket.
Could there be some way to list what critera is being used in the initial ticket?
I don't know how we could do that. It's true that sometimes people mention the criterion in Bugzilla while proposing the blocker, but it's a free-form text that we can't easily process. Also, often people don't mention any criterion when proposing this. And then people argue about the best criterion in the ticket. The arguing sometimes happens even if a criterion *was* originally proposed. So I don't know how to highlight it.
Is there any plans for a cleanup cycle? ie, now that f33 is out, close
out all the f33 tickets?
Yes, Lukas Brabec is working on it in https://pagure.io/fedora-qa/blockerbugs/issue/114
I always forgot what the commands were.
Alright, that's a similar feedback to Chris'. Could you specify what exactly did you not remember? The tracker names (FinalBlocker, FinalFE, etc)? Their CamelCase format (hint: case doesn't matter)? Or the order of the voting command (FinalBlocker +1)? Or just everything together?
I tried to create the tracker names in the same spirit as we use it at IRC meetings and in Bugzilla (well, in Bugzilla we use FreezeException instead of FE, but I thought everybody would hate me for making them write long words in each ticket). At IRC meetings we usually have the order reversed ("+1 BetaBlocker"), but I swapped it because it was easier to implement parsing with the tracker name being first, which also seemed more logical ("BetaBlocker +1").
It seems we definitely need some cheat sheet in each ticket.
What Adam and others have said, plus an expansion on "It'd be really
nice if the web UI showed the current vote counts from
the ticket.". Specifically, I'd like to see the IRC format include
something like
# info Current vote in ticket is (+X,Y,-Z)
I included that by hand when I was running the meetings, but it'd be
nice to let the computer do it for me. Additionally, we might want to
include the names of people who voted and how. Not as certain if I'd
actually want that or not.
Thanks everyone for feedback. This is very helpful. I can't promise we'll quickly implement most of this, but I'll try to prioritize the mentioned problems and regularly annoy Lukas Brabec (who's done most of the code so far) to make him fix them :-)
Please continue submitting ideas, if you have some. Thanks.
_______________________________________________ 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
