Re: Fixing the draft in TR space is continuously out dated problem

On 2014-10-26 21:18, Harry Halpin wrote:
> Everyone,
>
> Inspired by yet another really fun time trying to get a WD published, I
> propose that we get rid of the step of publishing separate WDs from the
> Editors Draft in /TR space entirely.
>
> I think the publishing of WDs before CR is a technical procedure that
> would have limited or no formal effect on W3C process and considerably
> negative effects on the standardization process insofar as it confuses
> developers/users and wastes the time of editors/Team. The formal impact
> is limited as I believe patent commits are made to the charter and the
> call for Exclusions happens at FPWD and then patents commits again at
> PR->Rec. Although I may be wrong, in between charter, FPWD, and CR no
> patent commits or exclusions generally are made.
IANAL - but that isn't correct.

If a W3C Member quits a WG, their licensing commitment is for the last 
published TR.   So, no TRs after FPWD means their commitment is to the 
first FPWD.
http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-resign

Patent commitments aren't made "to the charter".  It's Essential Claims 
in the spec.  You have to be able to see the spec to figure out what 
those may be.
http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential

Commitments happen when there are exclusion periods (FPWD, quit the WG, 
Last Call - in the new process Last Call happens at CR). Actual 
licensing is for a REC.



>
> Currently, the Working Draft publication process is at some date we take
> an arbitrary snapshots of the Editor's Draft (currently almost always
> maintained in Github rather than W3C.org space), do a week-long e-mail
> dance with pubrules, link checker and the Webmaster, and then publish a
> Working Draft in TR space - at which time this WD is usually *out of
> date* by the time it appears on W3.org.
>
> This by necessity leads practical WGs to emphasize a "living spec"
> procedure where we encourage people to look at Editors Draft and ignore
> whatever WD is at W3.org/TR space. No one really tracks the old
> "hearbeat" requirement anymore, as the action is in the bug tracker and
> Editor's draft.
>
> Further, it is made difficult to publish WDs in W3.org because of small
> issues with our somewhat clunky pubrules process and the fact that link
> checker is often excluded by robots.txt (for example, from fragid links
> to github) and the Webmaster basically acts like a robot that just
> checks to see Link Checker and Pubrules is fulfilled but cannot edit the
> HTML. It seems like if the Webmaster just acts like an automated checker
> for this clunky process, there's no reason not to replace the Webmaster
> with a fully automatic process for WD publication, as that would save
> both the Editor and Team time and the Webmaster could use their skills
> for something more important than running Link Checker, like fixing the
> rest of the W3C toolchain.
>
> So, a simple proposal to fix this situation is that:
>
> 1) After FPWD when a /TR URI is given, a simple automated snapshot of
> the Editor's Draft from Github (or wherever else it's maintained) is
> just sent automatically to the right w3.org/TR space. Thus, no more
> confusion between WD and Editor's Draft, because there would be *no
> difference*. At FPWD, a Call for Exclusions is sent.
>
> 2) Publishing WDs should no longer require any interaction with the
> Webmaster. The Team Contact or Editor should just be able to run
> pubrules, Link Checker, or whatever else they like and use their own
> judgment if they think something needs to be fixed - in which case, that
> fix should be reflected back into the Editor's version on Github.
>
> 3) The Webmaster and the full publication process is only required at
> the transition out of WD into CR, PR, and Rec (with usual calls for
> Exclusions).
>
> Does anyone see any utility in keeping publishing WDs separate from
> Editors Drafts?
>
> Apologies in advance if this has been discussed before.
>
>       cheers,
>         harry
>
>
>
>
>
>
>
>
>
>

Received on Monday, 27 October 2014 16:06:39 UTC