W3C home > Mailing lists > Public > public-w3process@w3.org > April 2014

Re: W3C events classification

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Wed, 09 Apr 2014 13:27:44 +0200
To: "Stephen Zilles" <szilles@adobe.com>, "Olle Olsson" <olleo@sics.se>, "public-w3process@w3.org" <public-w3process@w3.org>, "Jeff Jaffe" <jeff@w3.org>
Message-ID: <op.xd1rgizby3oazb@chaals.local>
On Fri, 04 Apr 2014 15:14:55 +0200, Jeff Jaffe <jeff@w3.org> wrote:

> On 4/3/2014 7:56 PM, Stephen Zilles wrote:

>>> -----Original Message-----
>>> From: Olle Olsson [mailto:olleo@sics.se]

>>> 1. what should be defined in the process document?
>>> 2. what kinds of open events should W3C be associated with in what way?
>>> and then also
>>> 3. how should W3C stakeholders be informed about events?

Yes, these seem to be the key questions.

>>> A tentative conclusion of the discussion is that it will be impossible  
>>> to specify in detail in the process document what kinds of events are
>>> appropriate for W3C involvement, and what kinds are not.

I think that is likely to be a conclusion. However, it is likely possible
to give some clear guidance.

For example, when does W3C get involved in a government-sponsored event?
Are there criteria for (not) supporting a commercial for-profit event, or
an academic event?

I would expect these to be in a guidance document with a reasonably clear
change policy and history, not a formal part of the process.

>>> The critical factors for judging possible W3C involvement in an event
>>> (whether as driving partner or by some kind of sponsorship) are:
>>>    * what W3C resources will be consumed (can these resources be used  
>>> better in other ways)?
>>>    * what is the effects on the reputation and trust of the W3C  
>>> trademark?


>>> Hence:
>>> 1. keep the relevant section of the process document as simple as  
>>> possible, stating a few priorities and some objectives.

Indeed. Essentially, I think minimum notice periods are important, and a
link to "how to organise a W3C meeting" is useful.

For what it is worth, I think it may make sense to combine "Group
meetings" and "other events" in the process.

>>> It should avoid specifying an ontology of meetings ( ;-) ) --
>>> such a thing will quickly become irrelevant.

Strongly agreed.

>> [SZ] One aspect of being a public standards defining organization (SDO)  
>> is that there are criteria that such organizations are expected to  
>> meet. Like many things these criteria are not clearly delineated  
>> anywhere, but common to many lists is the notion of "fairness". This is  
>> intended to mean equal access to the work of the organization by its  
>> members (and often by the public as well). For meetings this has at  
>> least three components: (1) members must have a way of being notified  
>> that a given meeting is occurring (see Point 3 below); (2) the notice  
>> must be given with enough advance notice that people can re-arrange  
>> their schedule to attend the meeting;

I mentally combine these as "transparently making it easy for people to

But yes, the fairness thing is important both in justifying how we do what  
we do, and in avoiding running foul of anti-cartel and  
anti-competitive-behaviour laws.

>> and (3) some useful record of the meeting is produced for those that
>> were unable to attend the meeting.

This is generally a sine qua non of W3C events. And the quality of the  
record is a good measure of the extent to which W3C is doing its job.

>> There is another aspect the size and place of the meeting venue that  
>> may also impact the number of attendees. If the number of attendees is  
>> limited, then having a "fair" selection process has been expected.  
>> (This is what led to the use of the technical based selection  
>> mechanisms that so many have complained about.)

>> It is the role of the Process to set standards that implement
>> "fairness". [...]

Well, it sets the requirement for fairness, and may include some of the  
baseline (i.e. essentially obligatory) requirements for implementation.

>> I would not expect the process to require a given notification
>> mechanism because communication technology changes sufficiently fast
>> that the Team should be given the role of suggesting appropriate
>> notification mechanisms.

Personally I disagree. I believe the Process should mandate at least 1  
channel that people can *rely*on* as a source of information, rather than  
hoping that if the team switches to Gists tomorrow, and decides in a few  
months to use a Google group, and then moves to something else, we all  
notice and follow them.

(This is closely related to the dashboard discussion. People want to know  
where the information they need will be found, I think even more than  
caring if it is in a super-digestible format.)

>> Whether the Process should say something about how meeting
>> attendance is determined when demand exceeds supply is a relevant
>> topic for discussion.

Indeed. Again, my personal take is that the process should require a  
documented process to be used, that is fair to the global stakeholders who  
have an interest in the topics on which W3C works.

>>> 2. W3C (the Team, in a broad sense) should be entrusted to make  
>>> decision on (morally) supporting relevant events that are organized
>>> by other parties (as long as the event is relevant for W3C work, and
>>> not eroding vendor independence).


Actually, I no longer believe in W3C as being very vendor-neutral, but I  
agree that it is an aspiration they should maintain and strive toward.

While the Team should indeed make the decision, as mentioned above I  
believe it would be useful to have a document, maintained by the team and  
referred from Process, a la Pubrules, describing the criteria for such  

>>> 3. calendars or feeds or whatever. For use by people in the W3C  
>>> garden; or by people in the outside world. People have many different
>>> preferences -- no size fits all.[...]
>> [SZ] One other aspect of the notification mechanism is the intended  
>> audience. [...]
>> Having said that, I am aware that real work is done by relative small  
>> groups of people not large meetings. We need to enable those as well  
>> and I am less sure on how to do that in a way that is "fair" to the  
>> whole W3C audience.


> I distinguish between an "event", trying to put a giant spotlight on a  
> new area, and "real work", which is often trying to design some piece of  
> Web architecture - either in a WG (for REC track) or a CG (for work that  
> is not yet REC track).
> We need to be fair to involve the global community (notification times,  
> public reports) for events.
> If there is a new WG or a new CG, it is also important that there is  
> awareness in the global community.
> I don't think that every time that several people in an existing group  
> get together to do some "real work" that there should be an expectation  
> of notification periods.  People already had received fair notice to  
> join the WG.  If interesting in the WG, they would be at the table if  
> the WG spun off a task force to do a certain piece of work.

This assumes that the WG itself runs according to a fair process and  
provides notification. In at least one important example (the Web  
Components get-together in California last year) this was not really the  
case. The Working Group followed process, by using the "get-out" clause  
that if nobody objects you can ignore the requirements, but I noted at the  
time that while I would not object I was unhappy with it happening this  
way and thought it would be a very bad precedent to follow.

The process currently decribes requirements for WGs (although they are  
extremely loose, and in particular there is no requirement to let people  
know through the "standard communication channel"). I hope such  
requirements, perhaps updated, will continue to be a part of the Process.



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
           chaals@yandex-team.ru         Find more at http://yandex.com
Received on Wednesday, 9 April 2014 11:28:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:17 UTC