W3C home > Mailing lists > Public > public-w3process@w3.org > June 2016

Re: Proposal to allow AC to initiate WG Charter AC Review - correcting format

From: wayne carr <wayne.carr@linux.intel.com>
Date: Fri, 10 Jun 2016 09:21:38 -0700
To: Stephen Zilles <szilles@adobe.com>, "daniel.glazman@disruptive-innovations.com" <daniel.glazman@disruptive-innovations.com>, "public-w3process@w3.org >> public-w3process" <public-w3process@w3.org>
Message-ID: <48dfc741-50f5-07d7-8aa0-576a02c8e9be@linux.intel.com>
It's a bit hard to see this one inline, so I'll top post.

Having a formal decision on whether to proceed with a request for a 
charter, that can be appealed (5% of the AC asking for appeal) is 
exactly what I'm looking for.

I thought Member submission is already there, so easy to change (they 
already have to respond to that).  But, having a separate requirement to 
do it some other way (like you proposed below) would be fine.

    Wayne

On 2016-06-08 22:14, Stephen Zilles wrote:
>
> -----Original Message-----
> From: wayne carr [mailto:wayne.carr@linux.intel.com]
> Sent: Wednesday, June 8, 2016 8:49 AM
> To: daniel.glazman@disruptive-innovations.com; public-w3process@w3.org 
> >> public-w3process <public-w3process@w3.org>
> Subject: Re: Proposal to allow AC to initiate WG Charter AC Review - 
> correcting format
>
> On 2016-06-08 04:25, Daniel Glazman wrote:
>
> > On 07/06/2016 20:49, wayne carr wrote:
>
> >
>
> >> A Member Submission may include a proposed Working Group Charter,
>
> >> where the request is for the Team to submit the proposed Charter to
>
> >> Advisory Committee Review for starting the Working Group.  Incubator
>
> >> specs for every proposed specification deliverable must be part of 
> the Member
>
> >> Submission, along with the Charter.   If the Team acknowledges a
>
> >> Submission, but rejects the proposal to Submit the Charter to AC
>
> >> Review, then the TAG,  AB or 5% of the AC may cause the start of an
>
> >> Advisory Committee Appeal vote as in Section 7.2.  That appeals vote
>
> >> would then decide whether to instruct the Team to prepare the Charter
>
> >> and put it to AC Review. The Director, for budgetary reasons, could
>
> >> choose to offer only minimal team support in the Charter for the 
> proposed group.
>
> >>
>
> > Wayne,
>
> >
>
> > All in all, I like the idea but I'm not so sure it's easily doable.
>
> >
>
> > I have a few issues to discuss: a Charter ready to be submitted to AC
>
> > review/vote should contain information about Co-chairs, duration and
>
> > more importantly Staff Contact. I don't see this happening without
>
> > prior contacts between the submitting organization and W3M so the
>
> > former would know if W3M is opposed to the submission of the Charter
>
> > to ACs or not...
>
> As the proposed text says, the usual path is doing this through the 
> team.  The question is what happens if the Director (i.e. W3C
>
> management) just doesn't want to do it. What this is about is making 
> sure the Membership can always create a WG if it wants to - that the 
> Team doesn't have a veto over what work the Membership wants to do.
>
> e.g. html5 vs xhtml type debate in the future.  Right now, there is 
> absolutely no way for the Membership to cause a WG Charter to go to AC 
> Review unless the Director agrees to propose it to the AC.  That's 
> what this fixes.
>
> I think it would be better if the Membership could cause an AC Review 
> on a proposed WG Charter if this extreme case every arose. Having 
> fallbacks like that I think prevents the need to ever use them -- just 
> because they're possible.
>
> As to the little things needed in the Charter, in this proposal it 
> still is the Team that makes sure the Charter contains what it needs 
> to -- this is about the AC being able to cause them to do that.
>
> >
>
> > Furthermore, the last sentence from your prose above does not seem
>
> > right to me: the Director is not here to offer team support and deal
>
> > with budget, the CEO is. The Director could veto the submission of such
>
> > a Charter to ACs.
>
> The W3C Process document is written in terms of the "Director" doing
>
> things, not the CEO.  In practice, the Director can delegate any way
>
> they want to -- it's just how the Process document describes the major
>
> roles.
>
> I don't know what you mean by "The Director could veto the submission of
>
> sucha Charter to ACs. "
>
> In this proposal, the Director cannot stop the AC from having an appeal
>
> vote that if it passed resulted in the Charter going to AC Review.
>
> After the AC Review, as always, the Director decides what the consensus
>
> is.  And, as always, that decision can be subject to AC Appeal.  That
>
> doesn't change. Once something gets to AC Review, there already is an
>
> "appeal" process where the Membership can override the Director
>
> decision.  This applies that to getting the AC Review started - so the
>
> AC isn't just reactive to proposals, it can initiate them in the extreme
>
> case where the membership wants something and can't get to an AC Review.
>
> So, this is very unlikely to ever happen -- but, if it does come up the
>
> Membership should be able to decide what WGs W3C forms.
>
> SZ: I think I understand you goal, "not allowing the Team/Director to 
> permanently block a work activity the Membership wants undertaken". I 
> think, however, having charters on Member submissions is not the best 
> way to achieve that goal. Under the current process, "W3C creates a 
> charter based on interest from the Members and Team." And, when the 
> Team gets a charter proposal, they are obligated to announce that they 
> are considering the charter to the AC (Section 5.2.2). This was done 
> to allow AC input to the charter document prior to an AC Review. Since 
> the AC is notified of a potential charter (independently of where it 
> originated) there seems little likelihood of the proposed charter just 
> be buried. I you are concerned about proposed charters just dying, 
> then it would make more sense to allow a (standard) AC appeal of a 
> decision to not progress an announced charter rather than establish a 
> special procedure for Member submissions. This means that if one or 
> more Members submit a proposed charter, then the Team should be 
> required to consider it and to announce their consideration. Maybe 
> this is what you had in mind with your proposal, but, if so, the 
> existing text implies (but does not require) consideration of charters 
> submitted by Members.
>
> There ought to be a minimum support requirement for proposing a new 
> Working Group (and thus a charter) outside the normal W3C Process. We 
> already require approval by at least 5% of the Membership in an AC 
> Review of a proposed charter. It seems to me that requiring 5% of the 
> Membership to support a charter that the Team/Director has refused 
> would, therefore, make sense (because it demonstrates that a charter 
> if sent for an AC Review would get the support it needs to progress 
> and Appeals of Director's Decisions also require support from 5% of 
> the Membership to proceed).
>
> There are (at least) two ways the Team/Director can fail to progress a 
> charter: one is by rejecting the charter outright and the other is by 
> failing to anything to progress it. Assuming the proposed charter is 
> announced (which is already a requirement) then AC Members can tell if 
> either of these approaches is burying the charter and they could 
> appeal (either the rejection decision or the lack of progress (in a 90 
> or 180 day period) and ask for an AC vote to promptly finish a charter 
> that can be sent for an AC vote.
>
> Would not this be a simpler process?
>
> Steve Z
>
> >
>
> > What if the chartered activity could be handled by an existing Group?
>
> > What if the whole thing does make sense as a Member Submission (a spec)
>
> > but none as a W3C WG?
>
> If it makes no sense to do, I'd think the TAG, AB or 5% of the AC would
>
> not ask for an appeal vote to request that it go to an AC Review of the
>
> charter.  And I'd assume if they did, the AC would not approve letting
>
> the Charter go on to an AC Review.
>
> >
>
> > </Daniel>
>
> >
>
Received on Friday, 10 June 2016 16:22:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 June 2016 16:22:42 UTC