Put Editor's draft on TR page, not heartbeat formal publications -> RE: Evaluating policies; pubrules

The regular TR heartbeat Working Drafts are often useless at best since they're so often out of date with where the WG is with the Editor's draft.  They also confuse people who don't know to look at the more recent editor's draft.  Publishing them more regularly seems like it would involve too much overhead.

Proposal: For WGs that have public editor's drafts, put the disclosure notice in the Editor's draft and put the Editor's draft on the TR page.  Don't publish regular formal heartbeat drafts.  Just publish formal versioned drafts for the required stages (First Draft, LC, CR, PR, REC).  Also, provide access to the editor's drafts under source control so people can look at it at a particular date if they need to.

>-----Original Message-----
>From: Dominique Hazael-Massieux [mailto:dom@w3.org]
>Sent: Tuesday, March 20, 2012 7:44 AM
>To: public-w3process@w3.org
>Subject: Evaluating policies; pubrules
>
>W3C is operating under a number of policies with various status and
>changeability.
>
>I haven't gone through all our policies, although in my previous messages I've
>already identified policies that could use to be revised (e.g. the normative
>dependency requirement, the determination of substantive changes).
>
>I think our point of reference for evaluating policies should be whether they help
>or not to achieve our goal (getting features deployed interoperably on a RF
>basis).
>
>A lot of them would probably need a big refresh under that light; I think we should
>try to identify which would allow the biggest gain in time in our day to day
>operations, and focus on those first.
>
>I think our publication process is a likely candidate (but that's a hunch, not at all a
>given). Each publication request can easily induce a week of delay (combining the
>transition requests, the two-days-per-week window of publication, and the need
>to make a document pubrules compliant). For a spec that goes through 10
>updates, that's 10 weeks of delay, so 2.5 month; not huge on the overall duration
>of our processes, but not negligible either. Also, it creates a psychological barrier
>to publication which likely has a bigger impact still.
>
>For all intent and purposes, pubrules is about packaging our specification.
>Packaging has a role in getting our specs implemented, and thus the features they
>describe:
>* W3C is (somewhat) trusted as a source of features
>* a given status indicator brings a given faith in the stability of the spec
>* the PP boilerplate helps enforcing the patent policy
>
>But it feels like the cost of enforcing all of pubrules uniformly is disproportionate
>with that benefits; for instance, it's not clear that having all internal anchors
>checked at FPWD is such a big win.
>
>A more productive way to ensure the packaging quality of our spec would be to
>provide tools of continuous improvement (e.g. check-on-commit, alert on
>regression, etc). A number of requirements that are "nice-to-have" but have low
>impact on implementations should move toward parts of the process where the
>work can be done without impacting the overall schedule of the work.
>
>Dom
>
>

Received on Tuesday, 20 March 2012 20:48:30 UTC