Re: Draft Charter

Mozilla's feedback, presented quoting Google's feedback (and responses 
to Google's feedback):



> On Fri, 20 Jun 2008, Matt Womer AT W3C wrote:
>   
>> I'm happy to say that a draft of the Geolocation charter is now 
>> available [1], [...] Any and all feedback is greatly appreciated, either 
>> here on this list or to myself directly.
>>
>> [1] http://www.w3.org/2008/06/geolocation/charter/
>>     
>
>   
For the record, Mozilla also expresses its disappointment that the 
Geolocation work takes place outside the Web Applications WG. The show, 
however, must go on, and Mozilla intends to participate wherever this 
work takes place, and to release products based on this specification.


>  - We think the first paragraph's emphasis on prviacy could mislead people 
>    into thinking that the API should constrain how user agents expose the 
>    privacy options to the user. We would like the charter to explicitly 
>    allow the deliverables to defer the user interface aspects of privacy, 
>    and the privacy model in general, to the user agents, within the 
>    constraints required to obtain interoperability at the API level.
>   

The sentiment that the charter should allow deliverables to defer UI 
aspects of privacy to the user agent is echoed by Mozilla.  However, I 
note that some aspects of the API do touch on privacy (e.g. we proposed 
"desiredAccuracy[1]" which is subject to modification as the 
specification progresses in the WG) and these aspects of the API might 
influence UI (see straw person UI[1] based on desiredAccuracy -- subject 
to change).

The existing charter language seems sufficiently "mushy" to me in the 
first paragraph ( to quote Jon Ferraiolo [2]).  Where appropriate, I 
think the emerging specification should call out the areas in which user 
agents ought to shoulder the onus for privacy in their own UI.  From a 
charter perspective, perhaps this "dual responsibility" for privacy 
(namely, interface design and UI within the user agent) can be made 
clear in the deliverables section.
>  - We think that the charter should not require the working group to 
>    publish the requirements as an explicit WG note. It should be 
>    acceptable for us to publish the requirements in the spec itself as an 
>    appendix, or on a wiki, or on our WG home page, etc.
>   
I'm not sure publishing a Note is that much overhead, since the 
requirements section seems small enough.  We think that the Note should 
be a deliverable, and are fine with the charter language here.
>  - We believe the timetable to have an unrealistic estimate for the time 
>    from CR to PR. Given the need to create a comprehensive test suite and 
>    to obtain two complete implementations, we believe it would be more 
>    realistic to expect the API specification to reach PR at the earliest 
>    one year after it enters CR, rather than three months later as in the 
>   
Mozilla intends to move rapidly with implementation, at least for a 
subset of requirements that this WG will develop.  Despite this, the 
timelines listed here are ambitious, and ought to be modified.  Three 
months seems quick; one year seems slow (for CR--> PR transition).  We 
echo Microsoft's suggestion:

"

 Would it be most prudent to charter the WG for a year period (which would, as Ian says, affect the end date), but enable the group to try to finish the test suite and obtain two complete implementations earlier if possible?

"


>  - We do not like that the group is expected to have face to face meetings 
>    and telecons. Our experience with other working groups in the past few 
>    years suggests that the group should not be required to meet, and that 
>    asynchronous communication media such as IRC and e-mail should be 
>    sufficient.
>   
API design decisions are best conducted with text-based communication 
media (including IRC and email).  But face to face meetings are very 
useful, and should not be discounted, and should be mentioned in the 
charter.  They may take place at general "big meetings" like TPAC.  With 
respect to weekly telecons, I'm inclined to agree that email-based 
discussion is better, but telecons should be called when necessary.
>  - We are not sure that the charter should explicitly expect the group to 
>    follow the AWWW and CharMod specifications. 
>   
We also concur; charter language should remove these explicit 
dependencies, unless anybody following this listserv can cite valid 
technical reasons for such dependencies.  We should proceed as we have 
w.r.t. proposals made to the Web Apps WG, making design choices public, 
and answering objections to design choices publicly (see below for 
mailing lists).  
>  - We do not believe there should be a member-only mailing list. A public 
>    group should be exclusively public.
>   
We believe that substantive work contributing to the specification MUST 
take place in the public mailing list, which, along with IRC, ought to 
be the primary discussion mechanism for substantive work by this WG.  
This should not differ from how we conduct work in the Web Apps WG.
We have no objection to the existence of a member-only mailing list, 
provided it is used for coordination and administration purposes.
>  - We believe that the decision policy should be ammended to explicitly 
>    grant specification editors broad responsibility for the specifications 
>    that they edit, requiring them to address the needs of anyone bringing 
>    feedback to the group, as well as requiring them to base their 
>    decisions on technical merit and research rather than on votes; we 
>    think that that decisions should explicitly not be derived from 
>    consensus. We think that the decision policy should say that the group 
>    has the right to replace the editor based on a vote, so as to 
>    safeguard against editors who fail in their responsibilities to the 
>    group.
>   
These are modifications to the Process Document, and are not in scope 
for an immediate charter review, although the suggestions are definitely 
worth following up on (and raise general observations about design by 
consensus).  The W3C Advisory Board has typically been custodian of the 
W3C Process Document.  I'd like this discussion to be initiated with the 
Advisory Board, and will put this on the upcoming meeting agenda. 

Ian: since you raise the issue here on behalf of Google, expect off-line 
/ off-listserv email from me about whether you can attend an AB meeting, 
and make this point there on behalf of Google.

I'd rather not stall work by trying to amend the charter to reflect this.
>  - We think that participation should be open to anyone on the same basis 
>    as the HTML working group.
>   
Certainly, Mozilla agrees that interested parties should subscribe to 
the relevant public listserv, where participation that is useful should 
not be discounted.

-- A*

[1] http://azarask.in/blog/post/firefox-geolocation-js-library/
[2] http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0110.html

Received on Thursday, 26 June 2008 03:06:28 UTC