Re: The Canvas 2D API split

On Mon, Jan 11, 2010 at 8:04 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> Hi Shelley,
>
> Thanks for your input.
>
> On Jan 10, 2010, at 7:10 AM, Shelley Powers wrote:
>
>> There was an original split of the Canvas 2D API[1], and an email list
>> created, supposedly to maintain it[2]. The proposal was created before
>> our change procedure was in place, so the item was left as a bug, and
>> the issue was never cleanly resolved. It just went into some form of
>> trackless limbo.
>>
>> Now, Ian has created a split[3], but there's no connection between it
>> and the previous work, and nothing from the originators of the
>> original split whether they're interesting in supporting one or the
>> other[4].
>
> It seems to me that neither Doug nor Eliot asked Ian's permission or
> approval before doing their split, and likewise Ian is not obligated to ask
> theirs. But ultimately, the Working Group will have to decide which of these
> Canvas 2D API drafts to proceed with.
>
>>
>> And the split document is confusing. In contains the line:
>>
>> "This specification is an HTML specification. All the conformance
>> requirements, conformance classes, definitions, dependencies,
>> terminology, and typographical conventions described in the core HTML5
>> specification apply to this specification. [HTML5CORE]"
>>
>> Actually, it is not an HTML specification. A 2D API is not HTML. And
>> the document references another document that has already been
>> rejected by the group, based on the other splits and merges that
>> happened this week.
>
> See my comments on the Communication draft. If and when this document gets
> to FPWD, we will have a bug component for it, and run the bug/issue process
> on the new spec in the usual way. We can even create a component ahead of
> time, if that would be helpful. Some suitable ways to object to such
> language in the 2D Context spec would be:
>
> - File a bug when/if the 2D Context component is created in bugzilla, and
> follow up in the usual way.
> - When/if the document is put forward for FPWD, raise a resolvable objection
> about this language (e.g. "I object to publication unless the claim that the
> specification is 'an HTML specification' is removed").
>
>
>> There are now two separate proposed splits, neither of which is
>> tracked, or part of an issue, and neither is there seemingly any path
>> forward in this group to resolve what I perceive to be a disconnect
>> between the original bug, and this week's activity.
>
> One thing we now seem to have consensus on is removing the 2D Context API
> from the main spec. Or at least, no one has objected to this so far. That's
> great. I believe closing out the bug is the right way to reflect that.
>
> 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.

>>
>> What II'm proposing is that this bug be grandfathered into the current
>> Change Proposal process, except that rather than muck about with the
>> bug, we create an issue for the split. We ask Adrian Bateman, the
>> originator of the original bug, and Doug Schepers and Eliot Graf if
>> they concur with submitting their original document as a change
>> proposal. We also submit Ian's as an alternative proposal, and we call
>> for a discussion on both, as well as other proposals.
>
> 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.

>> 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.

>> 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.

> 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.

>> 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.

> That's the end of my process comments as Chair.
>

I will look forward to hearing from the other co-chairs on this topic.

Shelley

> --------------
>
> For what it's worth, here's my own take (statements below are personal
> opinions and not with my chair hat on):
>
> 1) My understanding is that we had rough consensus that the Canvas API spec
> should be revised to include only the CanvasRenderingContext2D interface and
> related interfaces, but not the element. To date this work has not been done
> to Doug and Eliot's draft, but Ian's draft makes the split as agreed.
>
> 2) Doug and Elitot's draft has not been touched for over two months, since
> Eliot did his round of revisions. Prior to that, there was another 2 month
> gap after Doug's original check-in. It seems like Eliot and Doug may have a
> hard time getting this spec ready for Last Call in a timely manner, given
> their many other responsibilities. That's not to cast aspersions on them - I
> have also had the experience of signing up to edit a spec and then finding
> it a challenge to make the time.
>
> 3) Previously, Ian has said that he'll agree to split out
> CanvasRenderingContext2D if someone else does the work. Now he's showing
> willingness to do that work himself. I see this as a positive development.
>
> 4) There are a number editorial changes I would propose if and when Ian's
> draft gets to FPWD, to read better as a standalone spec. For example, the
> SotD section could use revision, and the "1 Conformance Requirements"
> section is missing the usual introductory material and instead jumps right
> into defining all the IDL interfaces. However, I am largely satisfied with
> the technical content.
>
> Thus, overall, I see Ian's draft as more likely to deliver a standalone
> canvas API spec as a timely manner, and therefore I think it would be in the
> best interests of the WG to go with that draft. However, I think meeting
> technical requirements, and showing a track record of responsible
> editorship, is more important than who edits. Thus, if Doug and Eliot's
> draft is updated to meet requirements and shows a track record of timely
> editing, then I will not have a strong opinion either way. (Yes, this
> contradicts my previous concerns about Eliot's editorship, which after
> further discussion and consideration I have withdrawn.)
>
>
> I would be interested to hear from Doug and Eliot on this issue.
>
>
> Regards,
> Maciej
>
>

Received on Monday, 11 January 2010 15:03:18 UTC