Compatibility/Meetings/2023-05-16

From MozillaWiki
Jump to: navigation, search

Minutes

  • Scribe: Dennis
  • Chair: Ksenia

Custom field for URLs in KB bugs neccessary? (dennis)

  • Dennis: I've been talking to bz people, and they would prefer us not use custom fields. Custom fields are possible, but they are global in bugzilla even if only used in one component. Can we use an existing field instead? I think we should be fine using an existing field. The URL field doesn't allow multiple URLs. We could use the user-story field, which is fine unless we need a second custom field. In that case we'd need a custom format. Right now URL is the only thing.
  • James: We can use the User Story field, but maybe we should design some basic syntax from the beginning, like `name:value` or something, so we don't lock ourselves out in the future.
  • Dennis: We _can_ have a custom field if we really need to, but we'd need to make a really good case. I'm also fine with a basic key:value syntax in there. I didn't want to make the decision unilaterally.
  • Honza: I agree too. Could also use an existing format like YAML.
  • Dennis: We also need a triage lead for the component. I'll nominate myself; we should get random bugs filed in that component.
  • Dennis: I'll change the design document to use the user-story field with a key/value syntax. We can always change in the future if required.
  • Ksenia: We could also use an attachment.
  • Dennis: I've been thinking about that, but you can't change attachments, just mark them as obsolete. If we upload a new text file every time we end up with a lot of obsolete attachments and there's no way to delete them. In this case we are likely to have frequent updates.
  • James: The other argument against attachments is that we're trying to get away from "you have to go into a text editor and edit a file manually and upload it".

WebCompat KB NG (Honza)

Actions/Status:

  • [Dennis] Create Bugzilla Component (for KB entries)
  • [Dennis] Setup DB and create tables in Mozilla's GCP BigQuery
  • [Ksenia] Collect more preferences through webcompat.com
  • [Ksenia] Create ETL script for importing data from Bugzilla to KB
  • [Ksenia/Dennis ready to help] Import existing web-bugs into KB
  • [Ksenia] Automatically import webcompat.com bugs in KB

About DB setup:

  • Dennis: I can now create db tables. I can also test the nodejs library and it seems OK. The remaining blocker here is BigQuery vs CloudSQL. I'm not yet 100% confident that we should use BigQuery. But that seems like the last remaining blocker.
  • Honza: I'll ping Anna; they should be back from the workweek.
  • Dennis: I can do that; I'll add it to my TODO.

About the pref collection:

  • Ksenia: I started looking at this. There are lots! Do we need them all or is there a limited set we want?
  • James: Tom's list is prirotized based on how important we think. But maybe we should collect them anyway just to test out the system? Or just a few, and then add later, because adding more prefs shouldn't be too complicated?
  • Ksenia: The anti-tracking features might be more than just adding a pref. I can ask Tom when he is back. But in the meantime, I can just add the straightforward prefs.
  • Honza: How is this going to work? Is there an addon, or is the code in m-c?
  • Ksenia: There's an addon inside mozilla-central. We already collect some prefs, and just need to add more.

ETL scripts:

  • Ksenia: No work on that yet.

Importing existing and new bugs:


  • Dennis: That's totally doable. There are bigquery libs for Python. The big blocker is knowing what storage we're using. We can't start with one backend and then change it later without big changes to the implementation. For existing web bugs we can use the ES data clone which we already have to avoid the GH API. For new issues we can do it directly in webcompat.com. I don't see a huge blocker on this.
  • Honza: Will we use github hooks?
  • Ksenia: For the new ones we can write to the new backend before the GitHub pipeline (before any filtering)
  • Honza: Is there any concern with private issues?
  • Dennis: I don't think so. We should dump all the reports we receive because this will be the most like we get from the new reporter. We will miss reports that are directly filed on GitHub, but that's very rare so we can ignore those; GitHub doesn't need to be involved at all.
  • Honza: Ksenia to own those?
  • Ksenia: I don't know about the existing issues / ES.
  • Dennis: I can help with that. I don't recommend the existing tooling. GitHub rate limiting is a problem for bulk operations. But we already have a nightly snapshot of the repo as JSON files, so you don't need to query the GH API at all.
  • Honza: are there any missing steps on the list?
  • James: Yes! We need to build up the infrastructure to do the triage on the issues and other things, but none of the things can be worked on (or even planned) unless the backend for that is up.

WebRTC issues (SV)

Since WebRTC is getting more visibility lately, is there a way to see when using Firefox (maybe in about:webrtc) if a website is using it? Would it be useful to add a Trend Label besides the existing [label](https://github.com/webcompat/web-bugs/labels?q=webrtc) for specific WebRTC issues, if we [QA] can differentiate issues specific for WebRTC?

We have documented around it and it seems to be used when using web apps for voice/video chatting that use your webcam, headphones and microphone, or for P2P file transfer. We have an ideea of how issues related should look like, but maybe there's a better way to find out if WebRTC is used.

  • Raul: We've seen that WebRTC-features are getting more visibility. There's a label on web-bugs for that, but we've been wondering if there is any way to see if a site is using WebRTC features. That would help us during triage.
  • Dennis: That's quite a complicated question. It's possible to see if a site is using WebRTC specifically. But a lot of media stuff isn't technically part of WebRTC; WebRTC itself is just the transport layer. All the device access is technically outside WebRTC. I don't have a good suggestion. It would be difficult to find a complete list of APIs that are relevant. Generally you can assume that as soon as microphone/webcam are involved it's probably WebRTC.
  • Simon: I looked at this a while back because Honza asked me. I wanted to detect if a site is a video conference site. There is a method called `addTransceiver` that's used for creating a video stream.
  • Simon: use counter for that: https://chromestatus.com/metrics/feature/timeline/popularity/2513
  • Dennis: WebTransport is now a thing, and big video conferencing sites might start using that instead.
  • Simon: Then they wouldn't be using WebRTC anymore.
  • James: The question is: what is the question? :)
  • Raul: To know if a site is using WebRTC, and to group them together for generating statistics.
  • James: It depends on if we care about sites using a specific technical feature, or if it's just a video conferencing site. There are also non-video-conferencing use-cases for WebRTC, like game streaming. I don't know if we care about "video conferencing" or "WebRTC" as a breakdown. Both might be interesting.
  • Raul: So should we just drop the trend-webrtc label?
  • Dennis: You could add a trend-videoconferencing label. That should be fairly easy to identify during triage, and is still meaningful.
  • James: That makes sense. That would be viable at triage time, and we can figure the actual implementation out during diagnosis. It seems more helpful to see if we're getting a lot of reports about video conferencing sites.
Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2023-05-16&oldid=1246506"