W3C home > Mailing lists > Public > public-w3process@w3.org > October 2014

Re: Can we discuss ISSUE-137 (rationalise heartbeats) please

From: <chaals@yandex-team.ru>
Date: Tue, 07 Oct 2014 00:03:38 +0200
To: "Michael Champion (MS OPEN TECH)" <michael.champion@microsoft.com>, Revising W3C Process Community Group <public-w3process@w3.org>
Message-Id: <60201412633018@webcorp02f.yandex-team.ru>
06.10.2014, 18:36, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>:
>> šI propose we remove section 6.2.7 Working Group "Heartbeat" Requirement.
>
> DL;DR - fix it don't kill it

TL;TD: We did, in ch. 7. That's why we don't need the chapter 6 version.

> In my mind this is tied up with the "graveyard of /TR" issue (there's probably a politically correct name/number I forget). šThe high order bit for me is to ensure that what is in /TR reflects the WG's current state of consensus about what is being worked on in editors drafts.

For this reason, I pointed out in my mail that the current chapter 7 (which would be unaffected by this proposal) has something like the heartbeat requirement. But instead of just showing that the group is alive, it promotes making a stabilised version of what is being worked on "every so often (see myearlier email for the more precise language we put into the process document a few months ago)", which SHOULD show what reflects consensus and what bits have open issues against them, and (unlike the IMHO broken section I propose removing) applies to all the things the Working group is doing instead of just "a draft".

> šPublishing a shapshot of the editor's draft every n months doesn't help anyone,

A stable draft between "significant changes that would benefit from review beyond the Working Group" does help people - those wh oare not following the group closely, don't need to, but do need to have some sense of what they are doing and what the results are.

> but motivating chairs to regularly assess stability, consensus, implementation, etc. status and ensure that reality is reflected in the /TR version of a spec should address some of the real issues that have come up in the Living Standards perma-debate.

s/chairs/group/ and I mostly agree with you. A /TR Working Draft *doesn't* reflect "reality", any more than an editor's draft full of the latest ideas (some of which are probably going to be thrown away soon as unworkable) does. Both kinds of draft reflect the reality that trying to write down standards is a messy process that continues for as long as the thing we are trying to describe is relevant to enough people, and that different people want different approximations to "reality" and are prepared to accept different classes of "rounding error" (to continue the metaphor).

cheers

> -----Original Message-----
> From: chaals@yandex-team.ru [mailto:chaals@yandex-team.ru]
> Sent: Monday, October 6, 2014 7:55 AM
> To: Revising W3C Process Community Group
> Subject: Can we discuss ISSUE-137 (rationalise heartbeats) please
>
> Hi,
>
> I think ISSUE-137 is very low hanging fruit. Can we open it and put it on the next agenda please?
>
> TL;DR: I propose we remove section 6.2.7 Working Group "Heartbeat" Requirement.
>
> Details:
> As written it requires groups to publish *something* every 3 months. Given that most groups make editors' drafts publicly available, and work on a public mailing list, the requirement to prove they are still doing something is redundant.
>
> In addition the mechanism is redundant, since the current process includes, in chapter 7, a requirement that groups SHOULD publish new Working Drafts when there has been a significant change - or every six months where that hasn't happened.
>
> The most significant change in practice would be making the Process about 1.5% shorter (based on the current draft).
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 6 October 2014 22:04:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:12 UTC