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

Re: Workshop and meeting requirements

From: Jeff Jaffe <jeff@w3.org>
Date: Mon, 12 May 2014 14:25:04 -0400
Message-ID: <53711200.1050209@w3.org>
To: "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, "public-w3process@w3.org" <public-w3process@w3.org>

On 5/12/2014 11:32 AM, Michael Champion (MS OPEN TECH) wrote:
>
> > This is a non-problem.
>
> ā€‹
>
> It's important to understand what what people THINK is the problem 
> before we try to solve it. Daniel has given his perspective on this 
> thread. Alex Russell had a  very fine rant 
> http://infrequently.org/2013/06/that-old-skool-smell/ā€‹ about what he 
> thinks the problem is a year ago. Iā€‹'m intrigued by the fact the W3C 
> TAG chose not to use the Workshop mechanism for it "Extensible Web 
> Summit"  (and still haven't published anything other than the raw 
> realtime minutes to summarize what participants said and heard, as far 
> I can tell).  Presumably there is a non "non-problem" with the 
> workshop mechanism or at W3C body such as the TAG would have used it!
>

I'm not sure I agree with this point.  I want to make sure that W3C 
makes it easy for people to get together under W3C auspices to solve web 
technical problems.  I don't care whether it is called a workshop or a 
summit.  The fact that the TAG found a way to meet to discuss web 
technical problems I view as a good thing, not a problem.

>
> Whatever the facts, it seems to me that more and more people are 
> PERCEIVING W3C as a place with all sorts of annoying rules that 
> constrain rather than promote collaboration.  That's wrapped up with 
> all sorts of other AC/AB permathreads about licenses, WHATWG, the open 
> source culture, etc.  I've heard the phrase "GitHub generation" used 
> to describe the people who want to get together quickly and usually 
> electronically to make tentative decisions that can easily be rolled 
> back or forked if they don't work.
>
>
> So if the GitHub generation continues to simply ignore us,  THAT will 
> be a problem.
>

I do agree with this.  If stakeholders ignore us because of our 
processes we need to fix our processes.  If stakeholders ignore us 
because of perceptions about our processes, we need to address those 
perceptions.

>
> -----Original Message-----
> From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru]
> Sent: vendredi 9 mai 2014 14:02
> To: public-w3process@w3.org
> Subject: Workshop and meeting requirements
> Hi,
> I am developing a proposal for the 19 May AB meeting on W3C's Workshop 
> and meeting requirements, and whether they need changes, and I am 
> offering it here for comment.
> TL;DR:
> + The requirements are basically "8 weeks notice for a physical meeting
> + in
> normal circumstances". This is reasonable and should not change.
> + We need to make it clearer what is required.
> + Meeting requirements SHOULD also include remote participation
> + facilities
> (at minimum IRC) and reasonably accurately real-time scribing.
> + Working Group decision-making procedures SHOULD be asynchronous.
> + Process Section 3.2 and Chapter 9 should be merged.
> ==The current situation
> The requirements are basically:
> For face to face events, there SHOULD be 8 weeks notice. Working 
> Groups can shorten this by unanimous agreement, Workshops can be held 
> at 6 weeks notice on "urgent topics".
> For virtual meetings there SHOULD be one week notice, unless it is 
> held at a regularly scheduled time.
> Agenda should be provided in advance of meetings, Action items and 
> minutes should be made available afterward.
> All WG members have the right to attend meetings of that Working Group.
> Workshop attendance is open to anyone.
> Workshops MAY use a structure such as requests for position papers to 
> allocate limited places.
> ==The problem statement
> The position paper/program committee structure has been claimed to be 
> inappropriate for many types of event. This is a non-problem. The 
> statement is true, but using such a process is entirely optional. It 
> is offered as one possible fair and transparent way to determine who 
> gets to take one of a limited number of places, in case that matters. 
> However we should clearly educate our community, especially our chairs 
> and those who organise meetings, on what the requirements are, and are 
> not, in this regard.
> The notice requirements are not, I believe, particularly onerous. In 
> many examples of events that "couldn't" happen through W3C, the normal 
> 8 week requirements could easily have been met. In others, it is not 
> clear that it was necessary to waive the normal notice requirement, 
> and it seems that doing so limited relevant people's ability to attend.
> The claim that "all the relevant people were available", in the 
> absence of any announcement, is unsustainable. W3C relies on 
> participants self-identifying as relevant stakeholders. The 
> opportunity to influnce the work of W3C is given to all such relevant 
> stakeholders, with the result depending on them doing work. Denying 
> Working Group members the opportunity to participate in a meeting is 
> counter to these principles.
> Failing to provide open and fair opportunity to attend relevant 
> meetings also probably violates the conditions under which W3C is an 
> ISO PAS submitter, and in extremis amounts to anti-competitive collusion.
> ==What to do
> W3C meetings are normally minuted in IRC, allowing at least minimal 
> real-time participation, and a detailed record. Working groups MAY 
> request a telephone bridge (or use some other mechanism) to allow for 
> real-time remote voice or video participation. W3C is apparently 
> investigating further possibilities for this.
> Some working groups have adopted requirements that binding decisions 
> can only be made asynchronously, providing a realistic opportunity for 
> those unable to attend a meeting to challenge a decision made by those 
> who were.
> Both these things are often part of the culture of groups, but are not 
> required and in some cases do not happen. They should be explicitly 
> noted as things that groups SHOULD do - and we should increase the 
> cultural expectation that they will be conditions of agreement to 
> waive minimum notice periods.
> Finally, the meeting requirements for Working Group meetings, and 
> Workshops (essentially meetings that do not cover chartered Working Group
> business) should be in a single section in the Process. There is a 
> very high degree of overlap, both in the existing text and conceptually.
> [1] Section 3.2:
> <http://www.w3.org/2005/10/Process-20051014/policies.html#GeneralMeetings>
> and chapter 9 <http://www.w3.org/2005/10/Process-20051014/events.html>
> cheers
> Chaals
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
> chaals@yandex-team.ru <mailto:chaals@yandex-team.ru> Find more at 
> http://yandex.com
>
> _________________________________ _
> This message and any attachments are intended solely for the 
> addressees and may contain confidential information. Any unauthorized 
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable 
> for the message if altered, changed or falsified. If you are not the 
> intended recipient of this message, please delete it and notify the 
> sender.
> Although all reasonable efforts have been made to keep this 
> transmission free from viruses, the sender will not be liable for 
> damages caused by a transmitted virus
Received on Monday, 12 May 2014 18:25:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:10 UTC