1. using BBEdit in reply to: Mozilla standards-positions issue 242

    I like the direction of simplifying our positions labels, and some degree of harmonizing for better communication. Rephrased from what I shared in some private discussions earlier this week: I think "support" may inadvertently convey a stronger meaning than what we intend a lot of the time. Similarly "oppose". One thing that other browsers explicitly look for are "positive signals" or absence of "negative signals", so I think it may be better to directly use such terms, e.g. "positive", "neutral", "negative" More: In my opinion this also reads better for evaluations of proposals which in their current state have more disadvantages than advantages, we can mark them "negative" without completely discouraging someone with "oppose" which sounds more like something we’d actively fight. Similarly, a lot of the time we don’t want to say "Mozilla supports X" if we think something has promise but has lots of holes to fill in or other problems. Such an expression may have the unintended consequence of discouraging (or deprioritizing) active work on the issues we file for such holes/problems. Also "support" is an overloaded term, that I’d expect broader audiences to possibly misinterpret as indicative of product plans. I believe "positive, neutral, negative" will more accurately convey what we mean than current labels, with less chance of misinterpretation (whether intentional or not) than the alternatives.

    GitHub post https://github.com/mozilla/standards-positions/issues/242#issuecomment-1228717449
  2. using BBEdit in reply to: Mozilla standards-positions issue 563 comment

    https://github.com/jfkthame I took a look and no particular concerns. I’ll label this `worth-prototyping` since it’s only in a Working Draft currently. Since https://github.com/emilio reviewed the code/tests, I’ll leave it up to him to review this too and close accordingly.

    GitHub post https://github.com/mozilla/standards-positions/issues/563#issuecomment-1225041063
  3. using BBEdit in reply to: W3C AB-public issue 5

    This is another “to-do list” issue that is open-ended and requires someone to go through a bunch of somewhat lengthy existing discussions elsewhere to try to extract specific proposals for improvement, similar in that regards to https://github.com/w3c/AB-public/issues/2 except that was primarily about extracting from a curated pre-existing crafted text, and this issue is more of an amalgam of a bunch of lists of things from several authors, some of which are already handled in the Vision. Similar to https://github.com/w3c/AB-public/issues/2: Proposed resolution: * defer this issue and leave it open to specific proposals (in new issues) for inclusion of any relevant specific points & content from the those old discussions. If there are no specific proposals by end of year 2022, close this issue without changes, noting that new issues for specific points may still be raised, yet due to lack of interest, no one is being assigned to attempt to extract specific points from other people’s lists made in GitHub comments. I.e. if folks feel strongly about specific points in their lists, it is their responsibility to file new specific issues for each point they feel strongly about.

    GitHub post https://github.com/w3c/AB-public/issues/6#issuecomment-1216042243
  4. using BBEdit in reply to: W3C AB-public issue 5

    Original issue both has some points and may be requesting more detail than is appropriate for a Vision document. Per the one response on the original issue, I’m not sure how to adequately address this issue either, except to perhaps consider linking to more detailed documents regarding “good of its users” and “safe for its users”, though I’m not certain enough about that approach to propose resolving in that manner. That is, this issue may merit some additional time and thoughtful consideration to come up with ways to address the points the original issue creator brought up. Proposed resolution: * keep this issue open to asynchronous discussion til the end of the year 2022. If it hasn’t made progress by then, consider linking the phrases “good of its users” and “safe for its users” to other related documents at W3C such as the TAG Ethical Web Principles https://www.w3.org/2001/tag/doc/ethical-web-principles/ Alternatively, if the AB deems that consideration (just linking those phrases to the TAG Ethical Web Principles) sufficient now, I would be ok with making edits to the Vision accordingly and closing the issue.

    GitHub post https://github.com/w3c/AB-public/issues/5#issuecomment-1216036403
  5. using BBEdit in reply to: W3C AB-public issue 4

    Original issue had one response pushing back on how this was attempted in crafting the Vision but essentially did not work in practice. Having worked on the Vision myself and seeing firsthand that combining principles related to the web and W3C in one document provides important context, and improves understanding & collective sense-making, I agree with the pushback. As there was no follow-up response (for nearly 3 months), and I don’t think this is worth pursuing: Proposed resolution: * close this issue without changes, as addressed by the response in the original issue and this follow-up comment.

    GitHub post https://github.com/w3c/AB-public/issues/4#issuecomment-1216030780
  6. using BBEdit in reply to: W3C AB-public issue 4


    GitHub post https://github.com/w3c/AB-public/issues/4#-1-by-tantek
  7. using BBEdit in reply to: W3C AB-public issue 3

    This is an astute insight. The Vision’s Purpose section https://github.com/w3c/AB-public/tree/main/Vision#our-purpose-focusing-on-the-integrity-of-the-web can be improved in many ways to more explicitly document W3C’s existing practices which serve the public at large. Proposed resolutions: * Add “and public feedback” to the end of the first point “Provide an open forum…” * Change “Ensure that standards are developed” to “Ensure that standards are openly developed”, perhaps defining “openly developed” in the Glossary per https://github.com/w3c/AB-public/issues/1 which could note that “openly developed” means publicly viewable discussion notes, proposals, issues, drafts, test suites, implementation reports, decisions, and conflict resolutions. * Add “for the public at large” after “… address evolving use cases”

    GitHub post https://github.com/w3c/AB-public/issues/3#issuecomment-1216024864
  8. using BBEdit in reply to: W3C AB-public issue 3


    GitHub post https://github.com/w3c/AB-public/issues/3#+1-by-tantek
  9. using BBEdit in reply to: W3C AB-public issue 2

    Archived link to said “7 points” document for context: * https://web.archive.org/web/20210507094551/http://www.w3.org/Consortium/Points/ There was a side comment in prior discussion of this issue to also consider updating other pages about mission, principles, and vision, such as: * https://www.w3.org/Consortium/mission However, “updating [other] existing pages” is off-topic for this specific issue, which is about updating the Vision document in particular. Proposed resolutions: * defer this issue and leave it open to specific proposals (in new issues) for inclusion of any relevant content from the old “7 points” document. If there are no specific proposals from the suggested old “7 points” document by end of year 2022, close this issue without changes. * create a separate new issue for “Update w3.org/Consortium/mission to align with updated Vision”

    GitHub post https://github.com/w3c/AB-public/issues/2#issuecomment-1216014305
  10. using BBEdit in reply to: W3C AB-public issue 1

    Proposed resolution: accept & resolve this issue: there was no objection in prior discussion, and it will help make the Vision more understandable to a broader audience, while helping it stay succinct which helps keep the Vision more accessible to a broader audience. Proposed next steps to close this issue: * create a Glossary file as a peer to the Vision document * stub it (explicitly) with scope (the Vision document) and one or a few obvious jargon terms from the Vision (e.g. “phishing”) with anchors * link to Glossary from the footer of the Vision document * link from the first occurence of a jargon term in the Vision to the specific term in the Glossary * add a “How to contribute” footer to Glossary encouraging proposed additions to grow the Glossary as necessary to define additional jargon terms in the Vision with broadly accepted uses & definitions within the W3C community, perhaps encouraging singular pull requests for terms that may require in depth discussion such as “centralization” or are otherwise contentious in actual practical use in W3C discussions. Aside: in the interest of re-use, resources at https://www.w3.org/Glossary.html may be helpful, but let’s please avoid the trap of creating yet another “system” (to be unmaintained & abandoned) like https://www.w3.org/Terms

    GitHub post https://github.com/w3c/AB-public/issues/1#issuecomment-1216007001
  11. using BBEdit in reply to: W3C AB-public issue 1


    GitHub post https://github.com/w3c/AB-public/issues/1#+1-by-tantek