Re: The Canvas 2D API split

On Jan 11, 2010, at 7:02 AM, Shelley Powers wrote:

> On Mon, Jan 11, 2010 at 8:04 AM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>>
>> What we now need to decide is what document, if any, we'll publish  
>> as a
>> replacement. The proper way to decide that is to discuss things and  
>> then put
>> forward one or more FPWD resolutions for API drafts. If we find  
>> that the
>> authors of both documents want them published and cannot reconcile  
>> their
>> differences, then we may resort to the issue process. But the issue  
>> process
>> is only for actual controversies, and not to be used speculatively.
>>
>
> The issue process is the only way that I know of to record actions,
> and ensure they're properly assigned and given completion dates.
>
> The Change Proposal process was initiated in order to handle
> controversy. The Issue Tracker is just one component of it. I don't
> believe that we should eliminate the one and only way we have of
> initiating actions, making assignments, and ensuring tasks are done in
> a timely manner by only allowing "controversial issues", based on some
> critieria, within the Tracker.
>
> The Canvas 2D API split ended up in limbo precisely because we didn't
> record the issue of whether to do this split in the Issue Tracker.

I don't think that's the case. The issue of whether to do the split at  
all now seems largely resolved. Or at least, no one is objecting. So  
that aspect is not in limbo. The progress of Doug and Eliot's document  
(and in particular the fact that it hasn't been updated to meet the  
agreed-upon scope, or proposed for FPWD), does indeed seem stalled. I  
don't believe an issue tracker issue would have made a material  
difference.

We have to keep in mind that the Change Proposal process exists for  
one reason: to resolve disagreements. It is a very heavyweight process  
that requires a lot of work from participants and the chair, and takes  
a long time to resolve. We should not be freely using the issue  
tracker for everything, only when we have actually found there is a  
disagreement that can't be worked out otherwise.


>> As stated before, we'll only resort to the heavyweight process if  
>> both
>> editorial teams want to proceed with FPWD and the Working Group  
>> only wants
>> to publish one of the two specs. In other words, only if there is  
>> an actual
>> controversy, not speculatively.
>>
>
> Then I'd like to record a action on both groups to respond to our
> request for clarification in a timely manner.

It looks to me like Ian has requested FPWD for his canvas API split.  
Is there any other input you'd like to see from him?

I agree it would be useful to hear from Doug and Eliot. I will  
encourage them to do so. If they don't respond in a timely manner,  
then likely we will give them a deadline, and past that will expect  
that we won't be hearing from them, and proceed on that assumption.


>
>>> We could potentially end up with a merged document as consensus, but
>>> right now, we have two documents floating around, neither of which  
>>> is
>>> a FPWD, and neither of which has an official path associated with  
>>> it.
>>> And I'm not terribly sure that either is a document we can live with
>>> -- a split of this magnitude should be discussed, and a formal
>>> resolution given.
>>
>> If anyone has a concrete objection to either document, then it  
>> would be
>> appropriate to raise it. The purpose of the issue process is to  
>> resolve
>> actual disputes where the parties feel so strongly that they want to
>> escalate. It is not appropriate to use it as a fishing expedition  
>> to flush
>> out objections.
>>
>
> Actually, I believe I did in this email.

Indeed, you did raise one specific point about the contents (that it  
calls itself "an HTML specification"). We need more specific points  
like that to be raised. I described two of the potential ways to get  
that comment (and any others like it) addressed.

>
>>> More importantly, we need to determine the proper home for the 2D  
>>> API.
>>> I do not believe the HTML WG is it. I do believe that it should have
>>> its own working group, and had thought the effort to create the  
>>> group
>>> was underway.
>>
>> It is a previously recorded Working Group Decision that Canvas  
>> (including
>> the 2D API) is in scope for the HTML Working Group. That doesn't  
>> mean we
>> *have* to publish it, but it does mean that we have decided that  
>> the HTML
>> Working Group is at least one suitable home. Per the W3C Process,  
>> that
>> decision can only be revisited if there is new information.
>>
>
> Or if a Formal Objection is made.

A Formal Objection does indeed trigger review by the Director, who may  
reverse the decision. It does not reopen the decision in the Working  
Group itself. If anyone seriously wants to enter a Formal Objection to  
this two-year-old decision, then the Chairs can certainly pass it on  
(along with any other relevant information) and try to get expedited  
processing. Or if anyone has concerns about whether due process has  
been followed in this matter, they may appeal to the Team Contact  
(Mike Smith).

Personally, I think a Formal Objection on this particular issue would  
face long odds, since the decision is an old one, interested parties  
have had due notice of it for some time, and nothing has changed  
recently that would affect the validity of the decision. But at least  
it doesn't create work for the whole Working Group.

>
>> That being said, I think our rough consensus (including Doug and  
>> Eliot) was
>> to publish a Canvas API spec as an HTML WG work item for now, but  
>> consider
>> moving it to a different group at some point in the future. I don't  
>> believe
>> there was any concrete effort ongoing to create such a group, but  
>> in any
>> case, it is a separate issue from doing the split or which  
>> standalone canvas
>> API spec to use.
>>
>
> At some point in the future seems to be the answer too frequently in
> this group. If we don't handle these items now, we will have to as
> Formal Objects when we try to proceed to the next step. The whole
> point on the new Change Proposal process was to hopefully have a
> process in place to resolve items so they don't have to go to Formal
> Objection.

The Change Proposal process is for resolving disagreement on changes  
to our Working Groups specs. It is not a process for creating new  
Working Groups or for other procedural matters of that nature. Nor is  
it a way to reopen past Working Group decisions.

>>> Though I agree with splitting the 2D API out of the HTML document, I
>>> don't believe the split should be impulsive, and without review and
>>> careful consideration. Or that we allow this seeming disconnect
>>> between the past effort and this week's effort to continue.
>>
>> I don't believe there was any review prior to Doug and Eliot's take  
>> at a
>> split, but that's ok, because there has been plenty of opportunity  
>> for
>> review since. And review of a concrete document is much more  
>> effective than
>> review of an idea. We can apply that same principle to Ian's take  
>> at a
>> split.
>>
>
> But no procedure in place to ensure that a formal review was made, and
> to put deadlines on such. Times have changed since then.

What kinds of specific deadlines would you like to see set? Should we  
give Doug and Eliot a deadline to propose their draft for FPWD or  
stand aside? Should we give them a deadline to comment? Note that the  
FPWD resolution itself, whenever it goes forward, will give everyone a  
deadline to object.

Regards,
Maciej

Received on Monday, 11 January 2010 15:31:51 UTC