- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 08 Oct 2009 01:24:22 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: HTML WG <public-html@w3.org>
Wow, you've got some tough questions. On Oct 8, 2009, at 12:26 AM, Henri Sivonen wrote: > On Oct 7, 2009, at 12:04, Maciej Stachowiak wrote: > >> It's very important for Working Group members to read this document >> and give questions or comments. Once we settle on a policy, we're >> going to follow the procedures outlined and will expect Working >> Group members to be the same. So now is a great time to ask about >> things that are unclear, or suggest improvements. > > It's unclear to me if issues can be revisited once an endpoint of > the escalation process has been reached. > > If person A escalates and indicates that (s)he'll produce a Change > Proposal but fails and the issue becomes deferred, can person B re- > escalate the same issue and undefer it? Can person A re-escalate? > (I'd expect it to be out of order if person A re-escalates.) I think it would be out of order for anyone to re-escalate an issue that has timed out (or a nominally separate but effectively identical issue). The process described does not currently give any way to re- escalate. But if someone actually puts forward a well-formed Change Proposal after that period, then perhaps we should have some way to still give it consideration. Perhaps only at the discretion of the Chairs, to avoid being delayed by last-minute Change Proposals. I welcome further input on this point. > If an issue has been resolved by consensus or vote (0, 5.a. or 6), > can a person who was a participant of the WG at the time escalate > the same or very similar issue? (I'd expect this to be out of > order.) What about a person who wasn't a participant of the WG at > the time of the consensus call or vote? (I think this wouldn't be > out of order per se but would be disruptive to allow.) If an issue that's already been decided is re-raised by anyone, the prior decision stands, unless new information is provided. That's standard per W3C Process. I don't think this is allowed by the policy as written (except perhaps by filing a new bug and refusing to accept that it is a duplicate; I assume we'd act to stop such activity). > Does anything above change if new information comes to light? Would > an implementor trying to implement and finding flaws count as new > information? Yes and yes. Perhaps we should spell this out. There's no provision right now to move a bug out of CLOSED state, but a new bug could be filed including the new information. > I gather that any feature that doesn't have two interoperable > implementations will get dropped before REC even if the WG has voted > to have the feature. Correct? That would depend on our CR exit criteria. I'm assuming our exit criteria will require two interoperable implementations of every feature, and that we would mark features "at risk" if there is a substantial chance of this not happening. In that case, the "at risk" feature could be dropped. If this happened with a feature not marked "at risk", we would have to go back to Working Draft to drop it, or be blocked indefinitely from getting to REC. For this reason, I would say any feature that doesn't have even a single implementation at Last Call time (conforming or not) should be marked as "at risk" in our CR exit criteria. All of this is somewhat outside the scope of the policy. > Is an accepted Change Proposal effectively an invariant section from > there on? Or may the editor make editorial changes to the text? I think textual changes that maintain the spirit and intent of the Summary in the Change Proposal should be allowed. > In any case, it seems to me that Change Proposals should come with a > copyright waiver, assignment or license that makes the Change > Proposal (if incorporated to a draft) not add restrictions to either > how the WHATWG licenses spec or how the W3C licenses specs. We did not think of that. The W3C Process document does not seem to cover copyright assignment or waiver. I am hoping someone from the W3C Team can advise on what is appropriate here. > Can a person who isn't a participant in the WG submit a Change > Proposal? If yes, does the person have to accept the PP to be > allowed to submit a proposal? I think we should say "yes" and "yes". The policy should be updated to say this explicitly. > This policy doesn't seem to cover how the WG decides to take on new > deliverables. Is that intentional? Taking on new deliverables in practice boils down to two publication decisions: publishing a First Public Working Draft and going to Last Call. I assume once we go to Last Call we likely intend to stick with it through REC, but FPWD does not carry any implication that we will proceed further on the REC track. We did not document the process for these kinds of publication decisions; the policy focuses on decisions about spec content. Do you think these steps need to be explicitly documented somewhere? Our de facto practice seems to be that a lazy consensus resolution or poll is sufficient for FPWD, but there is no precedent yet for LC. Regards, Maciej
Received on Thursday, 8 October 2009 08:25:01 UTC