softvision-sergiulogigan
commented
6 years ago What if, instead of having only one label, we have... three?
May I suggest a 4th one? Device (model/brand/[whatever])
Closed denschub closed 6 years ago
softvision-sergiulogigan
commented
6 years ago What if, instead of having only one label, we have... three?
May I suggest a 4th one? Device (model/brand/[whatever])
zoepage
commented
6 years ago In CSS we defined following: https://github.com/webcompat/webcompat.com/blob/master/webcompat/static/css/src/labels.css#L30
- label-browser
- label-status
- label-priority
- label-nsfw
- label-device
- label-osSo, we'd need to add label-platform, but I really like it. :)
reinhart1010
commented
6 years ago What if, instead of having only one label, we have... three?
How about adding another label called engine-{blink,edge,gecko,presto,servo,trident,webkit} ?
With this, we can distinguish issues which are found in specific engines instead of browsers (e.g. trident for IE, edge for Microsoft Edge (Win10), blink for Chrome/Opera/Chromium/Baidu Browser/Vivaldi/Falkon/QupZilla/etc., webkit for Safari/Epiphany/BlackBerry/Midori/etc., and gecko for Firefox/GNU IceWeasel/GNU IceCat/Pale Moon/etc.)
I prefer to use the main browser rendering engine names rather than CSS or JS engines, as most browsers have a similar combination of those engines (e.g. as in Chromium-based forks, Firefox forks, etc.)
reinhart1010
commented
6 years ago With this, we can distinguish issues which are found in specific engines instead of browsers
I have at lease compiled some user agents at https://gist.github.com/reinhart1010/c2312a779932ebccf409d8a3a93502b7 , which are categorized based on just 8 browser engines (including Goanna from Pale Moon). This could help simplify diagnosis.
Next, I think it's also fine to include the full user agent strings in future webcompat reports, so we can find further information, e.g. specific WebKit version, which could be helpful for diagnosis as well.
miketaylr
commented
6 years ago I think it's also fine to include the full user agent strings in future webcompat reports
Yeah, we actually capture that now, it's just hidden. Would be cool to expose it in the browser config details thingy.
karlcow
commented
6 years ago I made progress on this. See #1971 (#2471) I release an intermediary steps. Once it is deployed, I will see how it is working. And then work on the next step. I will clean up also the current labels.
karlcow
commented
6 years ago This was discussed during June 2018 All Hands in San Francisco. We agreed on the simplification and its terms. See https://wiki.mozilla.org/Compatibility/Meetings/2018-06-work-week#4.2_browser.2Fos.2Fformfactor_labeling_.28_.F0.9F.90.9D_.29
denschub
commented
6 years ago Thanks, @karlcow!
This was initially posted as a reply to #1971, but given the discussion'y and potentially lenghty nature of this subject, having an own issue is more appropriate.
Let's talk about browser labels. We have a lot of them, and the current situation is really bad and if we use any form of filtering of issues for our work queue (like I do), or use those labels to build metrics, that's bad.
I understand we trust user input here, and we also want to be able to create label on-demand. However, as I am currently a bit unsatisfied with not being able to reliably get a list of all Firefox issues, I'll ramble a bit.
Here is a list of all 81 browser labels existing right now:
After some quick eyeballing and shuffling lines around in my editor, we have, ignoring the operating system and the platform,
That's horrible. If I wanted to have a tool that randomly picks a Firefox issue for me to spend my work time on, I'd have to search for 38 labels. This is especially painful considering GitHub does not suppot OR-label queries.
Given the current state of labels, and the fact we want to build more tools working with issues, including tools generating meaningful statistics, I feel like I should take the opportunity to propose to reconsider labels. And by that, I mainly mean the current philosophy (especially the fact that labels can be created automatically) and the way we parse those information.
In my ideal dream world, we'd completely get rid of our current labels and re-invent the system. Now, I know that the world doesn't work that way, but I'll still outline my dream scenario, so we can maybe have discussions around that.
What if, instead of having only one label, we have... three?
browser-{firefox,chrome,safari,edge,samsung,...}to differentiate between the vendorsplatform-{desktop,mobile,tv}os-{windows,macos,linux,ios,android,...}I feel like this would be really, really helpful. Not only would it make my day easier, as I could simply search for
browser-firefox, it would also enable us to easily implement filters on webcompat.com, so people could find issues they are interested in more easily. As a nice side-effect, generating statistics on Firefox vs. Chrome, or Windows vs. MacOS, or Mobile vs. Desktop, would be really easy to generate as well.Now, obviously, implementing that based on our current parsing logic would be horrific, but as mentioned earlier, I am not too sure if that's actually needed. Instead, I'd probably implement a relatively simple parser that runs a series of checks on the string ("Does it contain Firefox?", "Does it contain Android?", "Does it contain Edge?", "Does it contain Ubuntu?"), collect each result together with its weight, and make a guess on the browser, platform, and OS. (I have a simple algorithm in my head already, but I'll skip over going into detail, as this is nothing more than a philosophical proposal, and I don't want to make this too long.)
If, for some reason, we cannot guess one of the parameters, I'd personally be fine with
browser-other,platform-other, andos-other. That'd not impact the search-ability at all, since the full UA and the browser field would still be in the issue, so still discoverable, while we have a base of data to improve our parsing rules, while at the same time not compromising our other labels in a large scale.I am aware that this would be less-magical than our current logic, and would require a patch if a new browser pops into existence, but fortunately, this does not happen too frequently. To me, this feels like something we can handle, if we get more reliable labeling out of it.
Maybe, this is something to think and discuss about. Maybe not. :)
(I am aware of #997, but this is talking about a lot of different labels, and different interactions, so that's probably some kind of meta issue, as this is only talking about browser labels. Also cross-referencing #1949 and #1971 for potential improvements on the current implementation)