Re: Editor's Drafts

https://help.github.com/articles/closing-issues-using-keywords/

It's a handy feature for situations where code merges === fixed/closed issues. In W3C WG process, consensus should be the only thing that closes and issue--not merely text/code in the editor's draft--which is what Gregg was explaining earlier.

Consequently, we either have a few issues to reopen or new issues to file which re-frame those issues against the current editors draft.

Anyhow. Avoiding the automation in this case does seem best. :)

Cheers!
Benjamin


--

http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung

________________________________
From: Harold Solbrig <solbrig@jhu.edu>
Sent: Wednesday, November 28, 2018 11:27 AM
To: Benjamin Young; Gregg Kellogg; W3C JSON-LD Working Group
Subject: Re: Editor's Drafts


What is this magic you are talking about?





Harold Solbrig





From: Benjamin Young <byoung@bigbluehat.com>
Date: Wednesday, November 28, 2018 at 9:34 AM
To: Gregg Kellogg <gregg@greggkellogg.net>, W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
Subject: Re: Editor's Drafts
Resent-From: <public-json-ld-wg@w3.org>
Resent-Date: Wednesday, November 28, 2018 at 9:33 AM



As long as we avoid the automated "Fixed" GitHub magic, I'm OK with this approach.



--

http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung



________________________________

From: Gregg Kellogg <gregg@greggkellogg.net>
Sent: Saturday, November 17, 2018 1:56 PM
To: W3C JSON-LD Working Group
Subject: Editor's Drafts



Recently, we had a discussion on if changes should be merged into the Editor’s Draft when some controversy remains. As I mentioned on this call, this puts me (the Editor) in a difficult spot, as the cumulative effect of un-merged changes makes it challenging to maintain and reconcile these PRs, and gets in the way of progress on other issues.



Looking at the W3C Process Document [1], you’ll find the following paragraph:



Working Groups and Interest Groups may make available "Editor's drafts". Editor's drafts have no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group, nor are their contents endorsed in any way by W3C.



Later, it describes the following responsibilities of the Editor:



It is the responsibility of these editors to ensure that the decisions of the Group are correctly reflected in subsequent drafts of the technical report.



My interpretation is that the Editor’s drafts represent the editor’s best understanding of group direction and that WG authorization is not required to merge changes into the Editor’s draft. Indeed, in the past, before GitHub and PR-Preview, working groups seemed to work just fine with the editor making changes based on group discussion. The group can then iterate over these changes until satisfied, at which point it’s reasonable to release an updated Working Draft. This does mean that, we can’t rely on the “Fixed in #xxx” commenting feature of GitHub to close issues where any controversy remains and will need some other WG action to close these issues.



Henceforth, my policy will be to make changes that reflect my understanding of group direction and leave a small amount of time for discussion on the PR before merging (2-5 days, depending). Any remaining issues, or disagreements with the details of those edits can be resolved through further issues and PRs, and of course, discussion on the calls. This is really better to keep a record of what the issues are, as issues often grow into discussions that have nothing to do with the original issue. This also means that the Editor’s draft most closely resembles latest understanding. When there is a point of contention, it’s reasonable to add “Editor’s Notes” or “Feature At Risk” markers.



Gregg Kellogg
gregg@greggkellogg.net<mailto:gregg@greggkellogg.net>



[1] https://www.w3.org/2018/Process-20180201/