New label status when bug is filed on bugzilla or another browser bug tracker

[magsout]

I'm looking for some issue needs diagnosis https://github.com/webcompat/web-bugs/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Astatus-needsdiagnosis%20sort%3Aupdated-asc

I think it would be interesting to add a new status for issues that have an open bug on bugzilla. For example this bug webcompat/web-bugs#4114. Easier and readable when we filter list on webcompat.

[miketaylr]

It's a good idea, I like being able to filter.

Any suggestions for what it might be?

status-blocked?
type-see-also-bugzilla?

Sometimes a corresponding bugzilla bug can be a dependency, or sometimes just created due to related issues.

[magsout]

status-blocked looks good. It's generic and understandable

[karlcow]

Let's back track before choosing names.

When do we have another bug on Bugzilla?

• The bug has the equivalent tech-evangelism issue on mozilla bugzilla. We usually close one in favor of the other. be webcompat to bugzilla or bugzilla to webcompat. On Webcompat we close with status-duplicate but we kind of lose the information about it (except reading comments)
• the bug has a dependency on a core bug on mozilla bugzilla OR chromium bugtracker OR … AND we deem that we can close this issue as a duplicate of this core bug.
• the bug has a dependency on a core bug on mozilla bugzilla OR chromium bugtracker OR … BUT we think we should still do outreach

[magsout]

the bug has a dependency on a core bug on mozilla bugzilla OR chromium bugtracker OR … BUT we think we should still do outreach

So in this case we let the bug open... so added the label here ?

more than 50% of those issue have a bugzilla open https://github.com/webcompat/web-bugs/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Astatus-needsdiagnosis%20sort%3Aupdated-asc

[miketaylr]

We could start with "status-see-bugzilla" and grow from there ("status-see-crbug"), etc. I don't like the semantics of "status-duplicate" when it's not a "real" dupe... feels like the wrong thing.

An example: webcompat/web-bugs#4726. It's a regression, and a bug is filed over in Bugzilla. But for me, we can close the webcompat bug now it because it will get fixed.

We could formalize a combination of the labels to signal the 3 cases @karlcow mentions:

1. status-duplicate && status-see-bugzilla (dupe of an existing bugzilla compat bug)
2. status-see-bugzilla && status-closed (go see bugzilla for a resolution).
3. status-see-bugzilla && status-needscontact (or outreach, whatever. the bug is still open, so stuff should still happen in webcompat land).

We could expose in the UI somewhere near the labels: Bugzilla NNNNN in a predictable place so you didn't have to scan all the comments (and this would encourage bad ppl like me to use webcompat.com over github :P)

[denschub]

Agreed!

We could expose in the UI somewhere near the labels

Question is: how do we get that information? By parsing all comments and looking for links to bugzilla.mozilla.org?

[miketaylr]

Question is: how do we get that information? By parsing all comments and looking for links to bugzilla.mozilla.org?

Hmm. Could be... maybe something more elegant (and less-error prone) like the See Also... field in Bugzilla. So something we would manually set, and then store in a DB.

[karlcow]

The thing I'm not comfortable with status-* is that I fear there could be a conflict of status, aka there is a dependency on a Mozilla issue or a chromium bug, but we still want to contact the site, it has happened.
There is also the possibility that it depends on more than one issue.

If there is a dependency I would call out this fact.

• dep-moz-NNNN
• dep-blink-NNNN

And indeed this could be exposed in the UI.

[magsout]

@karlcow

I fear there could be a conflict of status

Hum, why?

For you, what are the bests labels we can applied for this bug webcompat/web-bugs#4114 ? (for undesrtand your previous comment)

[karlcow]

After discussions on today's meeting.
dep-moz-NNNN might create issues by making the number of labels infinite. So not working as-is.

Instead we could probably create a magic string that we put in the first comment aka bug reporter.
We need to iron the syntax and think through it.

I'll come back to it tomorrow. @magsout I will explain the possible conflicts.

[karlcow]

Hum, why?

So let me rephrase the earlier comment. Some of the constraint

• We do not want bug to have multiple status-* labels
• The project will move to milestones instead of status-*. And this will enforce the unique status-
• It has happened in the past that we have an issue which is dependent on a core bug. For example, take the non-standard innerText which was not implemented in Firefox. We know the origin of the issue, so there is a dependency on the core bug. BUT we still wanted to contact the Web site (aka status-needscontact, status-contactready, status-sitewait), so they would fix their code by using the standard textContent.

It's why we need a system which is orthogonal to the status-* label.

Using labels for the dependency number as I was suggesting in #1339 (comment) is not a good idea. Thanks @miketaylr for pointing this out. Because we will end up with a lot of issues.

We probably could create a trick with a tagging system in the first comment of the issue. It doesn't even have to be visible but could be exposed in the UI.

But before jumping to the solution (this is often our mistake), what are we trying to achieve?

I think it would be interesting to add a new status for issues that have an open bug on bugzilla. For example this bug webcompat/web-bugs#4114. Easier and readable when we filter list on webcompat.

So issue 4114 is indeed a good example

• It is broken in Firefox.
• There is a possible fix min-width:0 to the img's .col ancestor, the issue seems to go away
• There is a firefox issue bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1136312
• The bug is to be switched to needscontact (just done that).

There are too options here:

• Wait for the firefox implementation difference to be resolved.
• Go ahead and contact the site with the suggested fix.

Whichever it would be good for people doing the outreach like @adamopenweb or me or anyone in the community to know the best course of action. To decide that we can indeed

• have a action label, not in status-*, for saying "on hold" ⏳ or "go" 🛎
• parse the comments OR the first report for grabbing the dependency information (first comment seems a better choice, but still not trying to jump to the solution)
• show the dependency in the UI (we need to come up with mockup for this)
• show the hold on action label/icon/color in the list of bugs and individual issue, so people will know to restraint their actions.

(I'm not proposing here below a design, or a mockup, I'm just illustrating the principle of this discussion)

Would this help @magsout to do a better job?

[magsout]

@karlcow oh ok, thank you for the Explanations. Sounds good, and yes I understand now. You're right 👍

[karlcow]

Per discussion we agreed that we need something for surfacing the dependencies. The next step is to figure out the UI, then the way we implement it. :)

[karlcow]

I removed myself of this issue.

This is a long summary of the issue on surfacing dependencies in issues.
#1339 (comment)

It requires a way to express the dependency.

I wonder if we should modify the initial description of the bug for adding the dependency/ies.