Re: Draft Charter

On Mon, 23 Jun 2008, Chris Wilson wrote:
> 
> 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.

I think we're on the same page here.


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

Agreed. Indeed, discussion over requirements has already begun and there 
is already a document listing the requirements put forward so far.


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

That seems like a good idea.


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

The very issue here is that not everyone agrees with AWWW and CharMod. For 
example, not everyone agrees on how API versioning should work, or on 
whether content-type sniffing should happen, or on how specs should say 
how to handle errors, etc.


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

Certainly we wouldn't want to prevent people who do like FTF meetings or 
teleconferences to use them, we just don't want them to be a required part 
of participation.


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

Indeed; the comment above was only referring to the member-only mailing 
list, which isn't required for the patent policy.


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

I'm not sure what this is referring to.


> > - 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 W3C is a dictatorship already, by design (with Tim as dictator, and 
the membership de-facto able to override him). Our suggestion is only to 
expand this model down so that it is also used "in the trenches", to avoid 
the rampant "design by committee compromise" that has affected so much of 
the W3C's work over the past 15 years.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 23 June 2008 22:31:25 UTC