Webcompat will move from whiteboard tags to keywords and a project flag to manage their work.

add the program flag with values

webcompat: ---, ?, -, P1, P2, P3

remove the existing flag

webcompat: ---, ?, +, -

Flag => program flag

• webcompat:--- => webcompat:---
• webcompat:? => webcompat:?
• webcompat:- => webcompat:-
• webcompat:+ => webcompat:p[1,2,3] depending on whiteboard

Whiteboard => keywords

• [needsdiagnosis] => webcompat:needs-diagnosis
• [needscontact] => webcompat:needs-contact
• [contactready] => webcompat:contact-ready
• [sitewait] => webcompat:site-wait

Whiteboard => program flag

• [webcompat] => ?
• [webcompat:p1] => webcompat:p1 if webcompat:+
• [webcompat:p2] => webcompat:p2 if webcompat:+
• [webcompat:p3] => webcompat:p3 if webcompat:+

:dylan, we need to turn the webcompat flag into a program flag.

Should I create a webcompat-new program flag, set that flag on the basis of existing metadata, get rid of the old flag, and then rename the new flag?

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #1)

:dylan, we need to turn the webcompat flag into a program flag.

Should I create a webcompat-new program flag, set that flag on the basis of existing metadata, get rid of the old flag, and then rename the new flag?

That might work! We should test on dev of course.

Who should be able to set the webcompat program flag values? Should that be anyone with editbugs, should we make a group to set the other values?

Let's start with editbugs. The list of P1 P2 P3 bugs is really small -- we'll catch any weirdness there I think.

I've created webcompat-priority and moving the whiteboard tags next.

I've updated the bugs to use the new flags and keywords.

I have two questions:

• if a bug has the whiteboard tag [webcompat] is the corresponding webcompat-priority ? or something else?
  When I look at the webcompat flag for those bugs (the one we are deprecating) I find three which have the whiteboard tag [webcompat] and webcompat+ https://mzl.la/2VyljxC
  Are these just bugs with inconsistent metadata we need to clean up, or does webcompat-priority need a + value
• the four webcompat: keywords: needs-diagnosis, needs-contact, contact-ready, and site-wait need descriptions

I'm holding off cleaning up the whiteboard tags to make sure I've transformed the data correctly.

It's kind of confusing, but [webcompat] does not necessarily imply webcompat?. Historically it's just mean "this is a bug that originated from webcompat.com, or affects a site". Nowadays, for important core interop issues we nominate things for tracking via webcompat?, and have kept the [webcompat] so I can add the priority, e.g., [webcompat:p1].

To be extra safe, I think Karl might be tracking the whiteboard, so let's consult him. Karl, would it break anything for you if Emma changed the [webcompat] whiteboard bugs by setting webcompat-priority: ?.

needs-diagnosis: Issues in the process of being analyzed to discover the root cause of the problem.
needs-contact: Issues which have been diagnosed and requires us to find a contact information.
contact-ready: Issues where the contact information has been found and are ready to be contacted. Anyone can do this. Be nice.
site-wait: Issues where we've done outreach and are waiting for the site to make a change.

Do we need webcompat-priority:untriaged or :+ for those cases?

Thanks for the keyword descriptions.

Looking again at the list, I think I would want [webcompat] to signify webcompat-priority: ? (that's effectively untriaged, we use the ?s to make decisions).

The question remains for Karl if he still has a use for the whiteboard item.

I do have mail search filters tracking [webcompat (not [webcompat] because mike introduced priority a while ago.)
But filters can be updated.

Let's see…

ok I just cleaned up my filters, and erased a couple of them and kept one only dependent on [webcompat

Let's do it. We will fix it step by step. There are some bugs with [webcompat (whiteboard), some with webcompat:(?|+|-) (flag), and some with both.

Thanks a lot Emma for all the cool work.

Emma, hopefully not too late -- but could we also add a value of "revisit" to the program flag?

(I forgot we were using a [webcompat-revisit] query to check out bugs we've triaged 6 months or so down the road, but aren't ready to prioritize them now)

no, I can do that.

I'm looking through this: https://bugzilla.mozilla.org/report.cgi?x_axis_field=cf_webcompat_priority&y_axis_field=status_whiteboard&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=cf_webcompat_priority&o1=notequals&v1=---&f2=noop&o2=noop&v2=&format=table&action=wrap and https://mzl.la/2DJKRxz to make sure we're mapping correctly

Can I go ahead and disable the old webcompat flag?

We can remove the old whiteboard tags after that.

I've created a GitHub issue to get a dashboard built: https://github.com/mozilla/fission-dashboard/issues/5

Emma, yeah, let's do it. Thanks!

Note: there is a [webcompat-sci-exclude] whiteboard tag I'm experimenting with that I'd like to keep for now.

Done.

Please remove all the [webcompat whiteboard tags except the [webcompat-sci-exclude].

Emma, sorry to pester, but are we still planning on adding a "revisit" value to the program flag? That came up in triage today. Thanks!

(once that's done, i can update the values from [webcompat-revisit] before Dylan nukes them, there's only 20: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%5Bwebcompat-revisit%5D&list_id=14726674)

That value has been added, remember its the "Webcompat Priority", not the "Webcompat" flag.

If that's not showing up for you, ping Dylan?

Yes, sorry. Webcompat Priority.

Dylan?

I see the revisit value for webcompat-priority for Firefox bugs as well as the other products enabled. Have you tried shift-reload to see if it will show up for you now?

dkl

Hi David, looking at this bug in Core, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=1432935. I don't have a revisit value. Same for a bug in Firefox.

Just confirmed, and twisniewski can't see it either. Would we need special rights to see that value (maybe??)?

(In reply to Mike Taylor [:miketaylr] from comment #23)

Created attachment 9068524 [details]
after shift-reload

Hi David, looking at this bug in Core, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=1432935. I don't have a revisit value. Same for a bug in Firefox.

Just confirmed, and twisniewski can't see it either. Would we need special rights to see that value (maybe??)?

Ugh sorry. I see now that the 'revisit' value had a group setting of editusers instead of editbugs. Which does explain why I could see it and you could not :) I have fixed it to be editbugs and you should be good now.

dkl

(In reply to Mike Taylor [:miketaylr] from comment #19)

(once that's done, i can update the values from [webcompat-revisit] before Dylan nukes them, there's only 20: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%5Bwebcompat-revisit%5D&list_id=14726674)

You should be able to complete this task now and then close the bug.

Awesome, yep. I see it now. :)

OK, that's done. I think the remaining bit is just "remove the existing flag". Emma, should I file a new bug for that?

No, I think we can clean up the existing values in this bug.

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #28)

No, I think we can clean up the existing values in this bug.

When you say cleanup do you mean move the old webcompat flag values to the new webcompat priority flag using the same values set? Maybe we can script that. There are currently 315 bugs with ^webcompat(?|+|-)$ set.

Also this can be done through the mass bug change UI but quite a bit of email will be sent out.

I think we just need to remove the old webcompat flag from the backend. We already migrated webcompat? -> WebCompat Priority?, etc once before, no need to do it again :)

(In reply to Mike Taylor [:miketaylr] from comment #31)

I think we just need to remove the old webcompat flag from the backend. We already migrated webcompat? -> WebCompat Priority?, etc once before, no need to do it again :)

It is already set as inactive which means it cannot be used for new values so that should be sufficient. So should we close this now?

Sure, I guess that works!