- From: Marcos Caceres <w3c@marcosc.com>
- Date: Thu, 3 Apr 2014 22:23:53 -0500
- To: Prod <spec-prod@w3.org>, Ian Jacobs <ij@w3.org>
- Cc: Arthur Barstow <art.barstow@nokia.com>
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