Re: ISSUE-41: Decentralized-extensibility - Straw Poll for Objections

Sam Ruby, Fri, 24 Sep 2010 09:10:15 -0400:
> On 09/24/2010 08:41 AM, Leif Halvard Silli wrote:
>> Sam Ruby, Fri, 24 Sep 2010 07:40:02 -0400:
>>> On 09/24/2010 07:12 AM, Leif Halvard Silli wrote:
>>>> Sam Ruby, Thu, 23 Sep 2010 22:28:42 -0400:
>>>>> On 09/23/2010 08:45 PM, Leif Halvard Silli wrote:
>>>>>> Sam Ruby, Thu, 23 Sep 2010 19:49:29 -0400:
>>>>>>> On 09/23/2010 07:19 PM, Leif Halvard Silli wrote:
>>>>>>>> Sam Ruby, Thu, 23 Sep 2010 14:12:51 -0400:
>>>>>>>>> The poll is available here, and it will run through Wednesday,
>>>>>>>>> October 7th(*):
>>>>>>>>> 
>>>>>>>>> http://www.w3.org/2002/09/wbs/40318/issue-41-objection-poll/
>>>>>>>> 
>>>>>>>> Co-Chairs and Mike,
>>>>>>>> 
>>>>>>>> Reading the socalled "zero-edit" proposal ("heavy-edit" would 
>>>>>>>> have been
>>>>>>>> more accurate names), I discovered info that we have not had in time.
>>>>>>> 
>>>>>>> The only relevant question at this point is whether the poll should
>>>>>>> be withdrawn, proposals updated, and then reissued.
>>>>>> 
>>>>>> I suggest that it should be delayed, yes.
>>>>>> 
>>>>>> ....
>>>>>>>> Firstly: The proposal referred to as 'zero-edit', consequently speaks
>>>>>>>> about Microddata as a "feature" (a feature of HTML), while whereas
>>>>>>>> HTML5+RDFa is presented as "applicable specification"extension. Draw
>>>>>>>> you own conclusions. Even if I would have agreed with that proposal,
>>>>>>>> those comments would hinder me from adding any support.
>>>>>>> 
>>>>>>> *shrug*  People sometimes believe strange things that are at odds
>>>>>>> with reality.  Unless those words appear in the document someplace, I
>>>>>>> don't think that is relevant.
>>>>>> 
>>>>>> It appears in the document many places:
>>>>> 
>>>>> Feel free to object to it.
>>>> 
>>>> "Unless those words appear in the document someplace"
>>>> 
>>>> We are supposed to give technically related response, but you suggest I
>>>> use space in the poll to object to a political matter.
>>> 
>>> You seem to be objecting to the change proposal.  There is a box for
>>> such objections.  If this objection is relevant, it will be
>>> considered.  In any case, I will strongly discourage this point being
>>> discussed further on this list.
>> 
>> So what did you mean by "Unless those words appear in the document
>> someplace"? Empty words? I have documented hat it is in the document.
>> Additionally, Julian has now documented those words appears in the
>> HTML5 spec itself:
>> 
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10717
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10718
> 
> Excellent!  Bug reports are a good outcome.  I suggest you follow 
> Julian's example.

It is great that he follows the discussion that you and I are having. 
However, we are unable to file a bug against the CPs.

>>> Perhaps the following commit is the one you are looking for:
>>> 
>> 
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/004101.html
>> 
>> Indeed. As Masata's messages shows,[*] the editor had a dialogue with
>> himself.
>> 
>> [*] http://lists.w3.org/Archives/Public/public-html/2010Sep/0275.html
>> 
>>>>> We have current allowed for two weeks.  Can you state how much time
>>>>> you feel would be necessary to study this proposal?
>>>> 
>>>> Those two weeks are for the voters. I think the CP authors should get
>>>> 3-4 weeks to see if they need to update their proposals. Thereafter,
>>>> the poll can be restarted. I will also consider reactivating my own
>>>> proposal.
>>> 
>>> I just want to be clear: you are asking for a delay because somebody
>>> *might* want to create yet another proposal?
>> 
>> It does not need to be created. It exists. It just needs to be updated.
>> I will update my proposal. Perhaps Robert's proposers would like to
>> update their proposal. And, without doubt, the co-chairs should now
>> admit the zero-edit proposal again, unless it removes it controversial
>> texts.
> 
> Correction: you withdrew your proposal, and nobody decided to pick it up:
> 
> http://lists.w3.org/Archives/Public/public-html/2010Sep/0186.html
> http://lists.w3.org/Archives/Public/public-html/2010Sep/0192.html

I don't know what you think you are correcting. 

> As near as I can tell, what you are suggesting is that each and every 
> time somebody updates a change proposal, a month should be added for 
> people to update their change proposals -- including ones that were 
> withdrawn -- and then... what?

I don't understand how you come to that conclusion. I propose a more 
adequate reaction below.

(W.r.t. my widthdrawal: I did not know, despite having asked in this 
group for info, that I did not have all info that I needed.)

>  Another month be added to allow 
> changes in response to these changes, and the cycle repeats again.
> 
> This is not a path that will get us to Last Call on a predictable schedule.

What would get us there, is that the co-chairs proactively coach the 
change proposals. You are yourself able to read and identify stumbling 
stones. You are yourself able to locate potential issues and inform the 
group. You are yourself able to say: "sorry, this proposal came so late 
that we need to start the poll later so everyone can considered it 
properly". That is what I expect from you as co-chairs.

I will also remind you that, earlier this year, you have yourself 
declared deadlines for how long in advance of a poll, a CP has to be 
ready. (And that time, the CP's were existing CPs - not entirely new 
ones.)

I prefer having an available, but heavily edited, CP available for some 
time, to not have any CP at all, until it suddenly appears right before 
the poll. Even if a CP is actively edited, it provides info and can be 
studied. You, the chairs, should take such info into consideration: 
When a new CP appears, then, if you want the CP to be considered in the 
poll, you should allow the CP to be studied. However, if an existing CP 
is updated, then that should not generally be a reason to delay a poll.

> I understand that you missed the original bug report, AND the change 
> which added some advice on how to do experimental non-standard 
> attributes, AND the change which tweaked the syntax, AND the fact 
> that the original syntax went out in the previous heartbeat draft, 
> AND the fact that the updated syntax was approved for the current 
> heartbeat draft.

And that no one answered my question in August. And that you approved 
Robert's proposal without informing him - or this group - about how his 
proposal conflicted with the up-coming "we defend the spec" proposal.

> I also understand that you decided not to pursue your proposal and 
> that nobody else saw a reason to support that proposal.  I have seen 
> no arguments put forward to indicate that there are any changes which 
> could be made to that proposal which would garner further support.  
> Without that crucial piece of information, I see it as highly 
> unlikely that the chairs will grant additional delays.

It would of course have been highly relevant in evaluation of my 
proposal to know that the editor supports something somewhat similar to 
what I propose.

With the new info that the zero-edit proposal has brought up (and much 
thanks to its authors for honestly using exactly the language that that 
the editor has used in the spec!), one must conclude that this group 
has not had the relevant info to evaluate whether mine proposal, nor 
Rob Ennals' proposal. And I don't think the chairs can have any reason 
to believe that I was alone in not being aware of Ian's 
_vendor/vendor-- solution: [*]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10720

> And I will reiterate: I continue to see it as entirely proper and 
> constructive for the draft to evolve towards a position which will 
> attract greater consensus, and see no reason to exclude the proposal 
> that contains the rationale for what currently exists in the document 
> simply because this work was done.

I don't know how you come to this conclusion.

What I said was that I see reason to do this: postpone the poll, let 
the authors update their proposals (if they want), let the chairs 
re-evaluate the quality of the proposals [*], and then (if there is 
more than one approved proposal) restart the poll.

[*] In which case _my_ advice is that you should not allow the 
zero-edit unless it update its controversial text - however, that is up 
to you, the co-chairs to evaluate. You are sovereign in your role as 
chairs. All we can do, is to appeal to the Director if we feel that you 
don't act as we expect.

I think you should allow us to evaluate whether you, after such a 
delay, would simply would stamp the existing proposal as they are, or 
not.
-- 
leif halvard silli

Received on Friday, 24 September 2010 15:42:30 UTC