Re: The Canvas 2D API split

On Mon, Jan 11, 2010 at 9:31 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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
>
>

Then I will enter an Issue, because I see two proposals, the editor
did not take into consideration the original proposed split, and I
don't agree with the wording of the editor's proposed change.

Shelley

Received on Monday, 11 January 2010 15:57:12 UTC