- From: <Frederick.Hirsch@nokia.com>
- Date: Fri, 4 Apr 2014 04:22:41 +0000
- To: <w3c@marcosc.com>
- CC: <Frederick.Hirsch@nokia.com>, <spec-prod@w3.org>, <ij@w3.org>, <Art.Barstow@nokia.com>
Marcos I would think that if someone spends the time and effort to contribute as an editor, they should be listed as such. If they are not contributing then perhaps should not be listed (or as editor of previous version). It also seems appropriate to list authors. Acknowledgements are sometimes tricky, but perhaps it is better to be inclusive. regards, Frederick Frederick Hirsch Nokia On Apr 3, 2014, at 11:23 PM, ext Marcos Caceres <w3c@marcosc.com> wrote: > 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 04:23:41 UTC