W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: Draft Charter

From: Chris Wilson <Chris.Wilson@microsoft.com>
Date: Mon, 23 Jun 2008 14:09:53 -0700
To: "public-geolocation@w3.org" <public-geolocation@w3.org>
Message-ID: <D12127075745E648BBC075EF46983E170C437B069D@TK5-EXMBX-W603v.wingroup.windeploy.ntdev.microsoft.com>

Maciej Stachowiak <mjs@apple.com> wrote:
>I have heard unofficially that someone made a private complaint to the
>W3C team about geolocation being covered in the Web Apps WG charter,
>and for this reason it was removed from the charter and a new group
>was created. If there are any good reasons that justify this decision
>made without any visibility or accountability, then by all means let
>them be stated.

As I've heard several people imply that the "someone" involved was Microsoft, I want to reiterate and elaborate on what I said in response to the Web Apps charter (via Michael Champion):  I wanted the charter to be more explicit about what goals the WG would have for a geolocation API, to understand the scope of such work even better.  I did NOT at any time request that geolocation be done in a separate working group or even state that I thought it didn't belong in the Web Apps group.  However, I felt "Geolocation API: to expose geolocation via an API" (or whatever the proposed charter said at the time, sorry I can't find it now) was not a sufficient description of the requirements for a charter.  I don't personally have a strong interest one way or another in where the API is developed - although it would be better in one sense to enable geolocation experts to collaborate without getting distracted by the other things the Web Apps group does, the overhead of one more group to join counterbalances that somewhat as well.  At any rate, Alec Berntson from Microsoft had already joined the Web API group intending to work on geolocation, will rejoin the Web Apps group as soon as we get the legal review done, and is already on this list.

Ian Hickson <ian@hixie.ch> wrote:
> - 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.

We respectfully disagree.  Although I agree with Ian that I would prefer the specification to not *constrain* how user agents expose privacy in the UI, I believe quite strongly that 1) privacy in the context of this API is incredibly important, as it has the potential to set up the future of web applications to be incredibly harmful to user privacy, 2) the _consideration_ of privacy and how it _might_ be exposed to the user might lead to different ideal design decisions in the API (e.g. if I know that the user might automatically enable "country and state" level of geolocation, then I might want to ask for just that precision - which, of course, would need to be reflected in the API.)  I do not think the importance of privacy in designing this feature can be overstated.

> - 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.

It would be a very good idea, in my opinion (and perhaps this is primarily related to the previous point about privacy) to get the requirements for the spec straight before writing the spec.

> - 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
>   current proposed charter. (This also affects the proposed end date.)

Hmm.  I agree 3 months is likely unrealistic.  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.

And our experience leads us to believe FTF meetings and teleconferences radically improve the team spirit of a WG, and lead to a much better, more collaborative specifications that satisfies more requirements across a broader spectrum of customers.

> - We are not sure that the charter should explicitly expect the group to
>   follow the AWWW and CharMod specifications.

Can you be more detailed about what constraints concern you here, as pertaining to the geolocation space?  As per your later comment on this thread, you cite versioning as if everyone agrees that the current HTML5 way is best.

>- We do not believe there should be a member-only mailing list. A public
>   group should be exclusively public.

Indeed, a public group should be public.  However, you seem to be ignoring how the (critically important!) Patent Policy of the W3C works.  I think it's fine to have the WG list publicly READABLE; however, not just anyone can join, without having to deal with the Patent Policy.  The group can, as always, have invited experts at the discretion of the chair(s).

In addition, I would point out that being a Member of the W3C has attendant responsibility (particularly around patent policy, but around architecture of the web in general); I would think there is value there for everyone that shouldn't be thrown away.

> - 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.

We disagree that the decision policies of the W3C and its Working Groups should enable dictatorships, be they editors or chairs, seemingly benevolent or otherwise.

The goal of W3C is to design collaborative specifications.  "Technical merit" is of course important; so is deployability and suitability to the industry.  Consensus is, in fact, critical.  If anyone on the group feels the wrong decision is being reached for the wrong reasons, they should appeal to the W3C management, and always (in my experience) have.

I'd also point out that "veto power of the group" means little when membership to the group is open - it seems I could mobilize 70,000 employees of Microsoft to join the group and outvote anything.  That seems like a bad idea.  The chairs (as per W3C Process) appoint and control editors; the Group leads control chairs.

> - We think that participation should be open to anyone on the same basis
>   as the HTML working group.

I think you have a very positive take on how well the HTML WG is performing that is perhaps not universally shared.  As co-chair of that group, I would not want to use its model as a universal model.  I'd much rather get the right set of stakeholders for a focused specification in a room, make their discussions transparent and the members responsible for their decisions, and get it done.

-Chris Wilson
Received on Monday, 23 June 2008 21:11:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC