RE: Suggested response to the Yandex "cannot iive with loosening of TAG participation requiremens"

Comments inline below
Steve Zilles

> -----Original Message-----
> From: Daniel Glazman [mailto:daniel.glazman@disruptive-innovations.com]
> Sent: Monday, April 13, 2015 9:41 AM
> To: public-w3process@w3.org
> Subject: Re: Suggested response to the Yandex "cannot iive with loosening of
> TAG participation requiremens"
> 
> On 13/04/15 17:36, David Singer wrote:
> 
> > What we wanted was that if someone changed allegiance, we (a) did not
> force a special election but (b) any >1 seat count for their employer would last
> no longer than until the next election. How the company resolves this -
> resignation, who resigns, when, term endings, etc. - is up to them.
> 
> "we"? Who's that "we"? Not me.
[SZ] I believe the "we" was the majority position in the discussion of this issue last fall. The position that led to a Call for Consensus on the text that is in the current Process 2015 Draft. 
> 
> Speak for yourself, Dave. It was never my goal and I think I'm the one who
> originally started all this discussion on the election after Alex's issue. My goal
> is to avoid a forced resignation, that I find a scandal and have always found a
> scandal. Read it again: a scandal.
> 
> The prose says the issue should be solved before the election. 
[SZ] I am confused by your reading of the prose, assuming that you mean the text of the proposed change to TAG participation. That text says, " At the completion of the next regularly scheduled election for the TAG" not prior to it. That was done to allow flexibility in the way a conflict (more than one participant from a single organization) was handled and to allow all participants to complete at least a year of their term. 

So the only way
> to do that is to make the extra seat's holder resign. *EXACTLY* the original
> issue, the original complaint from Alex, my original followup.
[SZ] Nit picking at bit. It is necessary that an organization end up with no more than one participant and the end of the election. If they had two participants and one's term was expiring, that person could choose not to run again and the problem would be solved without any resignations. 

 It's totally
> abnormal to force a resignation from someone who was elected, and it's a
> negation of ACs' sovereign vote.
> The Member company that acquired the extra seat holder's employer will
> force that individual to resign. Which is completely silly BECAUSE IF THE
> INDIVIDUAL LEAVES THE COMPANY, HE/SHE CAN RETAIN THE SEAT BEING
> UNAFFILIATED! Even worse, an extra seat's holder leaving the company, but
> contracting for that company, will retain the seat... Ooops.
[SZ] Your "Ooops" is valid, but the situation is not as clear as you indicate. Section 2.5.2 of the Process, second paragraph, says, " Each Member (or group of related Members) may nominate one individual. And, Section 2.1.2. item number 3., says, " two Members are related if, [...]The Members have an employment contract or consulting contract that affects W3C participation." So it would not seem to be possible for the contracting company to nominate a contractor if they had a participant. This is an area where some clean-up might be useful.
> 
> I'll do my best to block the current proposed prose, at all decision levels. It's
> severely suboptimal, ambiguous process-wise, and does not solve the original
> issue.
[SZ] I am not sure what you mean by this statement. One of the two proposed texts MUST be in the document. The issue is choosing between them. There is the text that is in Process 2014 which seems to be much further from your desired text and the proposed change which is nearer to your desired goal, but still lacking from your perspective. For Process 2015, those are the choices. It is, of course, possible to re-open a new issue for Process 2016 that would have different text.

> 
> > That's the theory, and I encourage you to read the previous comments to
> understand the concerns about this in practice.
> 
> Well I think it should be the practice. So if it's really only the theory, there's
> still a lot of work on the radar.
> 
> </Daniel>
>

Received on Monday, 13 April 2015 17:52:13 UTC