Add the most active issues as "under consideration". #66
Conversation
These issues seem worth trying to resolve first, and as part of being more public about that discussion, I'm going to explicitly list them as "under consideration" and reference their issues. This will thus link to mozilla#58, mozilla#27, mozilla#24, and mozilla#19. It also happens to include the first links to caniuse (the "ciuName" field being non-null). Note that activities.py normalized some whitespace in a prior entry added in mozilla#53. (I should figure out why it's always adding a space at the end of the line, but that's a separate issue. Until then, I'd rather keep the file matching the way activities.py regenerates it rather than having to hand-edit every time to avoid changing those lines.)
There was a problem hiding this comment.
+midi mozBugUrl: https://bugzilla.mozilla.org/show_bug.cgi?id=webmidi
+web-share mozBugUrl: https://bugzilla.mozilla.org/show_bug.cgi?id=webshare
+feature-policy mozBugUrl: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801
+permissions-api mozBugUrl: https://bugzilla.mozilla.org/show_bug.cgi?id=1105827
+permissions-api mozPosition: "important" /* supported in FF46+ per caniuse */
|
permissions-api mozPosition: remains complicated because that covers more than just |
|
I'm actually hesitating about the bug URLs, because I'm a little hesitant to drive traffic to bugs. |
|
I guess I should add the bugs at least, for the one that are in fact clearly metabugs for the entire spec. I'm inclined to omit those that aren't. I'll go through them later... |
|
https://github.com/martinthomson wrote:
In that case, shouldn’t we re-open https://bugzilla.mozilla.org/show_bug.cgi?id=1105827, and file new dependent bugs for what is not yet implemented / covered? https://github.com/dbaron wrote:
Makes sense. Worth adding to this project readme/how-to officially? As in something like: “The mozBugUrl field should only be filled in for "worth prototyping" or "important" standards, to avoid misdirecting higher-level discussion traffic to the bugs, which should be focused on implementation-specific discussions.” (Originally published at: http://tantek.com/2018/064/t1/) |
|
In that case, shouldn’t we re-open <https://bugzilla.mozilla.org/show_bug.cgi?id=1105827>, and file new dependent bugs for what is not yet implemented / covered?
It's better not to repurpose bugs; the history becomes unreadable, and regression/dependency tracking becomes unusable. If needed, a new bug should be filed, and if needed the old one could be retitled.
|
I suspect editors like to strip out this trailing whitespace (e.g., from mozilla#53) which activities.py then readds when manipulating the JSON (in mozilla#66). We'll avoid the churn (and annoyance) by not having the trailing whitespace at all. This sets the separators as described in the documentation at https://docs.python.org/2/library/json.html to avoid trailing whitespace when using indent. It also consolidates the JSON-writing configuration into a single place by creating a single JSONEncoder object.
I suspect editors like to strip out this trailing whitespace (e.g., from mozilla#53) which activities.py then readds when manipulating the JSON (in mozilla#66). We'll avoid the churn (and annoyance) by not having the trailing whitespace at all. This sets the separators as described in the documentation at https://docs.python.org/2/library/json.html to avoid trailing whitespace when using indent. It also consolidates the JSON-writing configuration into a single place by creating a single JSONEncoder object.
These issues seem worth trying to resolve first, and as part of being
more public about that discussion, I'm going to explicitly list them as
"under consideration" and reference their issues.
This will thus link to #58, #27, #24, and #19.
It also happens to include the first links to caniuse (the "ciuName"
field being non-null).
Note that activities.py normalized some whitespace in a prior entry
added in #53. (I should figure out why it's always adding a space at
the end of the line, but that's a separate issue. Until then, I'd
rather keep the file matching the way activities.py regenerates it
rather than having to hand-edit every time to avoid changing those
lines.)