On Mon, Nov 16, 2020 at 9:49 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> 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.
Fair enough. I think we can also try and edit titles to be more
descriptive if possible also. (On the bug side I mean)
Yes, but that would only apply before the blocker nomination is submitted. Once the ticket is created, further bug title changes would not be reflected.
However, I just realized that Blockerbugs WebUI already responds to bug title and component changes, I believe. So perhaps we could leverage this and update the ticket title if we detected a change in these fields. We wouldn't need to interact with Bugzilla (the data will already be in our database), which is great. We might also limit this to only cases when our bot already interacts with the ticket (a new comment is added), instead of attempting to have it always up-to-date, which might simplify it even more. We'll need to think about this.
Here's a 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.
We could provide some kind of numbering/index on the wiki to refer to
things? then add a thing to the blockerbugs proposal form to include the
section/number of the critera. But I agree that would be work...
People often add a hyperlink to the criterion in question (not using Adam's anchors, just ToC links, but that's fine) to a Bugzilla comment. At least I do it almost always (when I know which criterion to use, sometimes I don't). But I'm not sure how it helps. We can't enforce it (we don't want to prevent people from proposing blockers just because they don't know which exact criterion applies). The BBA proposal form is used only sometimes, many people propose it directly through Bugzilla, which is a free-form text field. And even the criterion that gets cited originally is often not considered the appropriate one. So if you want to vote, you still need to read the whole discussion (not necessarily the technical bugzilla discussion, but certainly the blocker discussion in our blocker-review Pagure repo, and at least the comment in Bugzilla which nominated the bug).
What we could do is try to link to the comment in Bugzilla which nominated this bug as a blocker/FE. It might be messy for some bugs (especially when proposed for multiple things, then retracted/rejected, then proposed again...), but it could help to find the "source" with some arguments of why this is even nominated (in a longer bugzilla report, I often search the page for "Blocks:" and that helps me find the nomination comment). This is not a bad idea, it just doesn't feel like an answer to your request (because the criterion mentioned there, if at all, might not be the one the others decided to vote against).
_______________________________________________ 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
