- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Mon, 17 Jun 2013 23:01:26 +0200
- To: "Jeff Jaffe" <jeff@w3.org>, "Arthur Barstow" <art.barstow@nokia.com>
- Cc: "public-w3process@w3.org" <public-w3process@w3.org>
Hi Art, (I still have in my backlog to answer your questions. Unfortunately there is a bunch of discussion tied up in AB minutes which are member accessible - so I presume you have read them - but not available to this CG, and other random places). Some of the problems I wanted to solve: In Last Call and CR especially * Going LC->CR->LC->CR... seems bad. * It strikes me that LC is a very important step for the patent policy, yet trivially easy for working groups to enter, with the only real check being the threat of returning. That threat is considered a certainty by many people and is therefore empty. * On the other hand, CR has a real check on entry, yet most of what it requires should already have been done, or will happen later. * I don't want to have a change that can only take effect by getting a change in the patent policy. (I think the patent policy should be updated to fix bugs, and maybe even changed, but having that as a dependency is something I only wish on a select few acquaintances) (These four reasons are behind merging CR and LC) Other things: * Getting WGs to get their testing story in order earlier would be good. But trying to do it with rules isn't a great idea IMHO. * A process that enforces either a waterfall model, a "super agile living standard", or something else, or prohibits any known model of development, seems like a bad idea. I've aimed to make them equally feasible under the same process (modulo the formal requirements of the patent policy - FPWD, LC, Rec). * There is no assumption made about versions, and whether there will be later versions of specs. I have tried to enable that as easily as possible without requiring people to do it. * AC review is sort of a member benefit that shouldn't entirely disappear - but often review would be useful earlier, especially positive statements of things the AC *like* in a spec. * The Process document is too long. Removing informative text may make the requirements clearer. * There are implied requirements, or requirements where there is nobody actually responsible for them happening. I have tried to clear that up. * the "post-rec" process is very unclear. Apparently groups can (and MUST) define errata, which can be normative and more or less anything. Tidying that seems helpful * The only mentioned use of a Note is for work that has been abandoned (at least "for now"). Yet in practice Working Groups and Interest Groups publish Notes for other reasons, and that should be clear. * Keeping the rules relatively short and simple reduces the odds that people will try "lawyering them" instead of actually making reasonable quality specs. On Mon, 17 Jun 2013 15:39:11 +0200, Arthur Barstow <art.barstow@nokia.com> wrote: > On 6/17/13 9:09 AM, ext Jeff Jaffe wrote: >> I'd be interested in your sense of the highest priority issues. > > The main pain point for me is the dependency "policy" blocks progress as > I already mentioned in > <http://lists.w3.org/Archives/Public/public-w3process/2013May/0020.html>. This is something that is in pubrules, not in the process. I agree it is a problem, but I doubt solving it in the process is the right place. In particular, I don't want to make the process as restrictive as the current pubrules, but I also recognise that the pubrules restrictions are there for reasons that are not just arbitrary. I also don't think the so-called "living standard" model is nearly as valuable as some of its proponents claim - there are serious problems with using it in situations beyond just patent lawyers counting angels on pin heads. I think there is work to do to describe the issues clearly, more to describe a solution which I expect to be something that covers both Editors' drafts and more stable releases of various kinds. And more work to get some reasonable level of consensus. Getting people to stop mixing politics with documents would be good for the Web. > I also provided information re the Process Document in > <http://lists.w3.org/Archives/Public/public-w3process/2013May/0015.html>. > To expand on section 7 a bit ... > > * One change I think would be useful is to be able to go from CR to CR > if no new features are added Yes. My proposal effectively allows this. > * It seems like PR could be eliminated if the Call for Implementations > included a clear statement to AC reps that it was their last chance to > submit comments. (For example, something like "this spec will advance > directly to Recommendation after the group has satisfied the Director > the spec has interoperable implementations".) I have more or less done this. There is still a period for AC review when the spec is "provisionally approved as a Recommendation" but that phrasing and some other stuff notes that there needs to be a pretty serious reason to overturn a spec at the end of an AC review. > Anyhow, it appears to me that combining LC and CR eliminates important > checkpoints Can you explain which ones? > and creates too many other issues You mean because about 20 issues were raised by the AB? FWIW I don't think that's much of a basis for judgement. The AB managed to address them all and either reach resolution or outline a clear basis to do so in less than a day, which might show they are super-efficient but seems to indicate to me that the issues were simple clarifications. I agree that the whole exercise could have been done in a more ideal way. This group was set up 18 months ago to enable that, but nobody took the opportunity to use it, and as a member of the AB I have felt generally bound to follow its processes first. > (to address a problem space that isn't entirely clear to me and > apparently some others as well > <http://lists.w3.org/Archives/Public/public-w3process/2013Jun/0021.html>). (I suspect there is stuff I forgot still...) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Received on Monday, 17 June 2013 21:02:05 UTC