Re: [Pubrules] Proposed changes regarding references to editors' drafts

comments inline... 

On April 3, 2014 at 5:38:22 PM, Ian Jacobs (ij@w3.org) wrote:
> =================
> Proposed Guidance
>  
> * Editor names. In each document (TR draft and editor's draft)
> indicate clearly who is editing the document. The list of editors
> may differ between the documents.

Something I've wanted to do for a while now is drop Editor's altogether and instead point to the contributor statistics for a specification. That gives a more fair view of who did what, doesn't discriminate (if you did something, you are listed. Period.) - and stops people free-riding. I've seen this a lot of free-riding in the forked WHATWG specs... it's yucky and has upset a lot of people in the past.   

https://github.com/w3c/manifest/graphs/contributors

> NOTE: The W3C Process states: "All other W3C editors MUST be
> participants in the group responsible for the document(s) they are
> editing." This applies to W3C technical reports. While it is
> possible for an editor of an editor's draft to not participate in a
> W3C group, it is important to understand any patent policy
> implications.

This is also made evident in my proposal above. As you can match contributions to pull requests and quickly identify any potential IPR issues. 

> * The Marcomm team seeks to balance editor innovation, application of
> W3C process and patent policy requirements, and consistency and
> usefulness for readers. To avoid delays after a publication
> request:
>  
> - Editors who wish to add features to the top of a W3C technical
> report beyond those described in the pubrules templates should
> consult with the Marcomm Team in advance.

We should come up with a enhanced set and add them to PubRules. It would be great to have, for instance:

* github repo
* link to bug tracker
* commit history
* Twitter account  
* link to test suite 
* link to "intents to implement"

All optional of course. 

> - Team contacts who observe consensus within a WG to publish a FPWG
> should contact the W3C Communications Team to begin to coordinate
> the publication.
>  
> * Here is recommended language for references to an editor's draft
> (for example, from a dismissable popup designed to attract the reader's
> attention).
>  
> - For a Working Draft: "Implementors should be aware that this
> technology is not stable. This draft captures the state of the
> document as of the publication date. The editor's draft may
> include bug fixes and other changes."
>  
> - For a Candidate Recommendation: "Implementors should be aware
> that the feature set for this technology is stable, although the
> details of those features may still change. This draft captures the
> state of the document as of the publication date. The editor's
> draft may include bug fixes and other changes."

This above two should be allowed to be popups as is currently done in the manifest spec. I had the ones I use in the manifest spec designed by a professional :) We could adapt those to have nicer colours or whatever.   

> - For a Recommendation: "Implementors should be aware that this is
> a stable document suitable for implementation; please check to see
> if there are any errata. For information about new
> developments related to this technology, see suitable
> reference."
>  
> =========================
> Proposed Pubrules Changes
>  
> * "Document titles/subtitles MUST NOT include status information or
> otherwise create confusion. For example the document title must not
> include status indicators such as "draft" or "recommendation" or
> "standard".

Should be ok. Though more explicit indicators might be nice ... like instead of just having the "WD" for basically anything on /TR/, it would be nice if FWPD and LCWD were clearly marked as such.  

> * Use these labels in this order to identify resources:
> "This Version"
> "Latest Published Version"
> "Latest Editor's Draft"

I would kindly ask that you flip the order (at least before REC). In terms of utility, the Ed. is infinitely more useful a link than any of the others to people that need to use these specs ever day. It's a continual source of frustration (for me) having to hunt down the Editor's draft (which is the only one I personally care about as an implementer/tester/reader).   

> * A document MAY include, near the top, guidance for providing
> feedback. Any such block MUST follow the Editors block. The
> recommended title for this block is "Feedback?"
>  
> * Departures from pubrules expectations for the top of a W3C
> technical report, or text in the status section that may cause
> offense or confusion MUST be approved by the Head of W3C
> Communications.

It's still a bit weird to talk about "causing offense". I don't think people do this on purpose. My initial set of changes with the manifest spec was just to better serve my audience/users... ok, and maybe to push the w3c to have this discussion... but I do it out of love, promise :)

Received on Friday, 4 April 2014 03:24:32 UTC