Fwd: Re: Expanded agenda and preread for 6 November meeting AB/TAG Experiment on the Device and Sensors formal objection

fyi


-------- Forwarded Message --------
Subject:  Re: Expanded agenda and preread for 6 November meeting AB/TAG 
Experiment on the Device and Sensors formal objection
Date:  Thu, 5 Nov 2020 16:24:37 -0800
From:  Reilly Grant <reillyg@google.com>
To:  Jeff Jaffe <jeff@w3.org>



I don't seem to have access to the mailing list on which Anssi shared 
his statement so I'll include it here. My apologies for getting this 
prepared late.

[==

This is a response to Mozilla’s Formal Objection [1] to the Devices and 
Sensors Working Group charter [2].

The following is my perspective as the co-chair of the DAS WG and a 
participant in the web standards community through various W3C groups.

Mozilla suggests that some of the proposed deliverables continue to be 
incubated in the WICG before being adopted by the DAS WG. It is 
generally our approach to both incubate in community groups while 
creating space in charters to enable more mature incubations to 
"graduate" without waiting for new charter opportunities. The charter 
would still clear this space if it introduced the contentious APIs with 
wording like "Depending on the level of consensus, the Group may deliver 
the following W3C normative specifications". We would prefer this 
approach over simply removing the contentious APIs because it creates 
space for the WG to discuss the APIs, which has been useful in finding 
compromises in the past. The DAS WG is the only group that can grant 
these proposals a higher level of IP certainty, so allowing their 
adoption within the charter length would appear to have benefits for the 
entire group.

I’ll use the Ambient Light Sensor API and the Network Information API as 
examples since they were both discussed at the group’s most recent F2F 
meeting at TPAC 2020. The Ambient Light Sensor API has seen relatively 
little interest from implementers, with Firefox implementing and later 
removing an earlier version of the proposal while Chrome has continued 
to maintain an implementation behind a flag but has not made a decision 
on when to ship it. At TPAC the group agreed that the use cases were 
insufficient to make work on the specification a priority at this time 
and the group resolved to continue to solicit feedback from developers 
in order to understand their needs in this area and that work could 
resume given new information. The interest expressed by developers so 
far indicates that there is a need for a capability in this area while 
the specifics still need to be worked out.

In the case of the Network Information API the group agreed that there 
are unsolved problems the proposal could address but that the design and 
use cases for the API need to be reevaluated given improvements made to 
other specifications in the areas such as bandwidth adaptation and lazy 
loading. It was agreed that there are likely still parts of the 
specification which are valuable, such signals about metered 
connections. This discussion kicked off renewed interest in 
collaborating with the Web Performance Working Group on the future 
direction of this deliverable.

The group had very similar discussions with regard to the Wake Lock API 
during and following from TPAC 2019 which resulted in changes to the 
proposal that convinced Mozilla that the specification was “worth 
prototyping”[3].

What I take away from each of these examples is that a forum for the 
discussion of these APIs is necessary in order to make progress in 
discovering the core issues that need to be addressed and reaching 
consensus on solutions. It is disappointing to see feedback on these 
APIs being delivered unilaterally through the Formal Objection process 
rather than being discussed with the group as part of our normal business.

- Reilly, DAS WG co-chair

[1] https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html
[2] https://www.w3.org/2020/05/proposed-das-wg-charter.html
[3] https://github.com/mozilla/standards-positions/issues/210

==]
Google Logo  
Reilly Grant
Software Engineer
reillyg@google.com <mailto:reillyg@google.com>
Google Chrome



On Thu, Nov 5, 2020 at 5:15 AM Jeff Jaffe <jeff@w3.org 
<mailto:jeff@w3.org>> wrote:

    Agenda:
    1- Introduction to this meeting (chair) (5 minutes)

    This meeting is an experiment/incubation for the proposal to have a
    W3C Council in place of a W3C Director to decide on Formal
    Objections. While the rules governing such council have not been
    agreed upon, we are mimicking the current proposed rules that are
    found in the Editor's Draft of Director-free. Due to this being an
    experiment, any TAG/AB participant who recused themselves or
    abstained is still welcome to stay as an observer for the purpose of
    the experiment but cannot participate *in any fashion *(with the
    exception of agenda items #4 and #5 below). The deliberations of
    this experiment are confidential to the participants. Any
    recommendation made through this experiment will be advice to the
    W3C Director, who intends to make a decision by November 20.
    Ordinarily, the team contact for the Working Group would make an
    initial proposal how to resolve the objection and W3M (acting with
    delegated authority from the Director) would decide the issue.  In
    this instance, we expect the experimental council will recommend how
    to resolve the objection and we hope that W3M will decide as per
    this recommendation.  If not, we would schedule a discussion between
    the experimental council and delegates of W3M.
    Since the formal objection was raised by Mozilla, individuals
    affiliated with Mozilla must recuse themselves.
    For the list of participants and interpretation of rules, see
    https://www.w3.org/2020/10/das-ab-tag-exp.html
    Jeff Jaffe will serve as Chair for the first call, while Peter Linss
    will serve as Chair for the second call.

    Clarification questions during agenda item 2, 3, 4 are welcome but
    other questions directed to the presenters must be held until agenda
    item 5. For questions directed to other participants or arguments,
    those must be held until agenda item 6.

    2- Presentation of the Formal Objection (plh) (10 minutes)

    The Team will summarize the nature of the Formal Objection as stated in
    https://lists.w3.org/Archives/Group/group-w3c-council-exp/2020Oct/0001.html
    As mentioned above, the team contact typically prepares an initial
    proposal to address the objection to W3M.  In this instance, due to
    the accelerated schedule, W3M has not reviewed this - so it does not
    yet have the status of a proposed objection resolution.  However, it
    is useful for the Council to see how this is usually done.  It is
    found at:
    https://lists.w3.org/Archives/Group/group-w3c-council-exp/2020Nov/0002.html

    3- Comments from the Device and Sensors Working Group Chairs (Anssi
    and Reilly) (5 minutes)

    Statement from Anssi Kostiainen, Device and Sensors Working Group
    co-chair:
    https://lists.w3.org/Archives/Group/group-w3c-council-exp/2020Oct/0002.html

    4- Comments from Mozilla (Tantek) (5 minutes)

    5- Questions from the *participants directed to the individuals who
    presented*on the previous items (2, 3, and 4). (30 minutes)

    Before agendum #6, the DAS Chairs will be asked to leave the call.
    Tantek Celik is welcome to stay as an AB observer.

    6- Open Discussion of the participants on the formal objection (30
    minutes)

    7- Next steps (Chair) (5 minutes)

    As a reminder, the agenda for the second and final call is.
    Email discussion will be encouraged before the second call,
    including additional questions and proposals for resolutions.

    - Based on the Doodle poll, the only time that is available for the
    Chair is 11 November at 17:00 UTC [1].   That currently seems to
    work for most of us, so we will go with that time unless serious
    issues arise with it.

    1. Summary of email discussion and proposed resolutions (Chair) (5
    minutes)
    2. Converging on a resolution (50 minutes)
    3. Resolution (5 minutes)
    (only if one or more proposed resolutions emerged from the previous
    item)
    This may include a vote if the Group is unable to get consensus on a
    resolution.
    If a resolution is made, a participant will be asked to write down
    the resolution by November 13. If a draft is produced, other
    participants may provide feedback on the draft until November 16.
    If a vote occurs, participants who disagree with the decision may
    write a Minority Opinion explaining the reason for their
    disagreement by November 16

    Jeff
    [1]
    https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=11&day=11&hour=17&min=0&sec=0&p1=43&p2=195&p3=224&p4=33&p5=248&p6=136&p7=64&p8=216