When do we publish a FPWD?

[msporny]

When should we publish an FPWD. Our charter says we should do it next month (Nov 2019). We do have a document today that allows us to publish a FPWD. Can we set a date when we're going to kick off the FPWD process?

[iherman]

As far as I am concerned: any time, and as soon as possible. Having the FPWD means that there is a clear, and public, stake in the ground by the WG, and that may be important for the community. We would also have a stable URL to refer to publicly (allowing us, e.g., to settle #52). Last but not least, it starts the patent policy process.

For our own work: that would also allow us to use Echidna meaning that we would have an easy way of set up an automatic publication process; i.e., we can publish to /TR easily without further admin.

In practice: I presume there are still PR-s out there that are relatively easy to handle and merge. There are also a number of editorial issues. I would think that if we merge the easy PR-s (if any) and settle the easy editorial issues then we would be at an equilibrium point to publish. But that is a personal opinion; we could go to FPWD even earlier.

---

We will have to have a separate discussion on how exactly we want Echidna to work for us. But that is after FPWD.

[msporny]

In practice: I presume there are still PR-s out there that are relatively easy to handle and merge.

All the current PRs we have (except for maybe one) out there are going to be difficult to merge and require more discussion.

There are a bunch of editorial things, but whether we get to them or not before FPWD isn't really a big deal. I think we're at a stable-ish enough point to do a FPWD (yes, it's early, but we are benefiting from the years of work that went into the CG spec).

I'd like us to do an FPWD ASAP, get our shortname configured, and get Echidna set up. /cc @peacekeeper @talltree.

[iherman]

All the current PRs we have (except for maybe one) out there are going to be difficult to merge and require more discussion.

O.k., understood.

As I said, whenever the group feels like it, I believe it is doable. The FPWD publication requires some extra administration, and rounds of publication steps, but that is what I am paid for:-)

[selfissued]

We already have a public working draft at https://w3c.github.io/did-spec/, which relieves the pressure to publish an official first public working draft. While it's not necessarily supposed to, people tend to view the FPWD as being reasonably stable and reflecting working group consensus.

I know that that other W3C working groups that I've participated in have waited to publish a FPWD until they've at least gone through the open issues and tried to resolve each of them that they could gain consensus on. I think we should likewise resolve what issues we can before publishing FPWD.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Manu Sporny: See Issue #68
Ivan Herman: A First Public Working Draft is the first of a series of drafts at w3.org/…
… This becomes a reference to the world.
… All the drafts will then be accessible.
… It starts the IPR process.
… Members can review and start any legal process required.
… Once this is published we can change our publishing method to quickly publish updates.
Ted Thibodeau Jr: +1 FPWD at editors’ will
Brent Zundel: It does not have to reflect consensus.
Ivan Herman: It just starts the process. Many changes can occur. This draft is way beyond the normal starting draft.
Phil Archer: In my mind we shouldn’t publish a spec working draft until we publish our first use case document.
Justin Richer: My qualm is re: document structure. Can we split or add to the document?
Manu Sporny: Justin_R, yes, absolutely, we have A LOT of structural flexibility.
Ivan Herman: Yes we can.
Justin Richer: Discussion at IIW and DID resolution brought this to my attention.
Ivan Herman: +1 to markus_sabadello
Dave Longley: +1
Orie Steele: +1
Brent Zundel: +1
Manu Sporny: +1 to markus_sabadello
Drummond Reed: +1
Markus Sabadello: This first draft would help people know that this is where work is continuing on this topic.
Manu Sporny: I agree in principle with Phil, but without firm knowledge of when the other docs will be ready, let’s publish the working draft now.
Drummond Reed: I agree in theory with phil, but I am having trouble referencing the right document.
… In issue #18 regarding resolution should not prevent publishing a working draft.
Manu Sporny: +1 to publishing DID Spec FPWD ASAP
Brent Zundel: I agree with manu, markus, and drummond. I would really like a working draft now.
Michael Lodder: +1 to publish
Brent Zundel: Anyone opposed?
Samuel Smith: +1 to publish
Dave Longley: +1 to publish
Kenneth Ebert: +1 to publish
Orie Steele: +1 to publish
Ivan Herman: We also need a formal resolution and another one on using Echidna
Manu Sporny: +1 to using Echidna!
Drummond Reed: +1
Manu Sporny: please please please let’s use Echidna
Adrian Gropper: +1
Michael Jones: There’s already a public draft at https://w3c.github.io/did-spec/
Ivan Herman: We also have to include in the resolution what the short name is. Is it then ‘did-spec”
Drummond Reed: Understood, Ivan, we appreciate it.
Drummond Reed: Yes, please, make the short name did-spec
Michael Lodder: as long as we can change it later if needed
Manu Sporny: Notes vc-data-model … alternatives could be dids or did-data-model
Michael Jones: We already have public working draft on github.
… Until we resolve some fundemental issues, we shouldn’t publish a working draft.
… Consensus is implied.
Manu Sporny: -1 to wait on “resolving issues”… FPWDs don’t need group consensus.
Justin Richer: +1 to mike’s point
Michael Lodder: there might be multiple specs
Phil Archer: Why “DID spec” instead of
… “DID”
Ivan Herman: First working draft does not imply consensus.
… There are several recent examples.
Drummond Reed: To Phil: first reason is to distinguish between the spec and when you are talking about a DID (as a identifier or a scheme)
Manu Sporny: +1, FPWD does not imply group consensus…
Michael Jones: In other groups I was in, we didn’t do that until some fundamentals were settled.
B

[iherman]

@selfissued,

I do not think I agree with your assessment. There has been many cases when drafts radically changed, possibly even several times, during their lifetime in a Working Group, and they do not necessarily working group, let alone community consensus. It is 'just' a stake in the ground and everybody in the group knows that the document will undergo major changes.

B.t.w., it is also customary for some groups to make references to open issues in the document (respec has some great tricks to make that easy). You can see an example for how it looks like. It means that it becomes perfectly clear where the possible discussion points are. @msporny @talltree @peacekeeper, maybe this is something we could do, and that may help to dissipate the problems.

(formally, https://w3c.github.io/did-spec/ is not a FPWD. It is an editor's draft, which is also correctly said in the header. I know I am a bit splitting hairs but, because a FPWD is also bound to a legal process on IP, we should be careful about the terminology.)

[msporny]

I know that that other W3C working groups that I've participated in have waited to publish a FPWD until they've at least gone through the open issues and tried to resolve each of them that they could gain consensus on.

We currently have 55 issues, many of them are in active discussion with unknown time frames for resolution. We have 12 PRs, many of them needing discussion with an unknown resolution time frame. I don't think it's a good idea to delay FPWD especially because of the unknown issue/PR resolution time frames.

The current specification has benefited from years of incubation in a W3C CG (as well as IIW, RWoT, MyData, and a variety of other venues). This document is well beyond what is normally considered an FPWD (given the various W3C WGs I've participated in over the past 10+ years).

All that to say, I'm hearing concerns and alternatives, but not hearing objections to a proposal to publish an FPWD ASAP... so let's get on with it and:

• record group consensus to publish an FPWD ASAP
• pick a short name
• publish the FPWD
• get Echidna set up

... and get past this first hurdle. :)

[selfissued]

I wasn't suggesting waiting a long time. I was suggesting that we take one pass as a working group through the PRs and issues and apply/fix those that we have quick consensus on, so we've dealt with the low-hanging fruit before publishing. We could probably make the decisions of which to address on the next call, and have those addressed by the following one.

[iherman]

I was suggesting that we take one pass as a working group through the PRs and issues and apply/fix those that we have quick consensus on, so we've dealt with the low-hanging fruit before publishing.

This is what I also raised in #68 (comment), to which the reply was:

All the current PRs we have (except for maybe one) out there are going to be difficult to merge and require more discussion.

(see #68 (comment)). In other words, I believe we are past that point per the editor(s).

I repeat my proposal here: let us select the really hard open issues and add a reference to them explicitly to the document (e.g., putting a reference to issue #5 is important, so that implementers would know that the context URI will probably change, but #19 is probably not that important in this respect). This is a one time editorial pass, I presume; I believe that the document can be published after that, and would also be an answer to the valid concerns of @selfissued.

[burnburn]

W3C has been consistently VERY CLEAR that WORKING DRAFTS DO NOT IMPLY CONSENSUS.
While we can perhaps be friendlier to external readers by linking GitHub issues, that is not in any way a requirement on WGs. Moreover, we are in the early days of GitHub issues, and keeping up with manually linking all new "hard" issues as they come in can be quite an editorial burden. Later in the process as we get closer to full consensus this becomes critical, but I would hate to add unnecessary load on the editorial team at this time.

However, early publication of an FPWD is extremely valuable. It officially starts a couple of IPR disclosure clocks, for one thing. Although the WG needs to vote to publish, I would strongly prefer that the WG take the advice of the editorial team on when to do so. If the editors find it easy to add the links (and can commit to keeping them up-to-date), then fine.

Publication as an FPWD is an editorial and IPR thing. Let's not make it into something else and unnecessarily delay this important first step by the working group.

[burnburn]

We already have a public working draft at https://w3c.github.io/did-spec/, which relieves the pressure to publish an official first public working draft. While it's not necessarily supposed to, people tend to view the FPWD as being reasonably stable and reflecting working group consensus.

I strongly disagree with both of these statements. First, an editors' draft absolutely does not start the IPR disclosure clock, which the FPWD does. Second, it has been more than a decade since I last encountered any expectation that a group have any consensus before publishing an FPWD. The mantra for many years now has been 'publish early, publish often'.

I know that that other W3C working groups that I've participated in have waited to publish a FPWD until they've at least gone through the open issues and tried to resolve each of them that they could gain consensus on. I think we should likewise resolve what issues we can before publishing FPWD.

I think Manu has stated above a clear opinion that we have indeed already done that, merging those that had quick agreement. @peacekeeper @talltree do you disagree?

[selfissued]

I'm fine with publishing a FPWD to trigger the resulting IPR commitments once the chairs have determined that we've addressed all the low-hanging fruit in the current issues and PRs, provided that people are clear that the resulting document is a point-in-time publication and not necessarily reflective of having achieved consensus on outstanding (or future) issues.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

3. FPWD
Daniel Burnett: #68
Daniel Burnett: key points… No Working Draft is meant to imply consensus, and this is explicitly stated in the Status Of The Document.
… No group agreement is required for most WD publications. FPWD starts some IPR commitment clocks which are important to Rec Track.
… WG could agree that FPWD happens when Editors think it’s ready. WG could agree on a specific date for FPWD.
Michael Jones: thinks the chairs should decide whether FPWD is ready to publish
Daniel Burnett: sure. WG could also decide to publish today, with doc as-is.
… WG members are expected to speak up if Editors make changes that don’t seem to match group decisions, or seriously conflict with their own positions.
Manu Sporny: this doc has been “in process” for months/years, and all low-hanging fruit / easy issues have already been dealt with; the remaining issues are fairly meaty, and may take some time.
… opinion as editor is that doc could easily go out today
Amy Guy: +1 publishing soon, we can release new WDs when things change. FPWDs don’t need to be at all polished
Drummond Reed: today would be fine; end-of-month cutoff would also be fine.
Markus Sabadello: +1 agree with manu and drummond, we can publish now or very soon
Drummond Reed: +1 to giving us one week, then publish after next week’s call
Drummond Reed: I love it—Halloween Edition!
Daniel Burnett: let’s set a one-week deadline for raising anything that someone feels MUST be changed before FPWD
… objections?

[selfissued]

Our charter https://www.w3.org/2019/09/did-wg-charter.html states that we are producing a Use Cases document defining requirements that the DID specification is intended to meet. Having the Use Cases document is therefore necessary to be able to evaluate the DID specification.

Therefore, I request that the working group review the Use Cases document and agree that it's ready for publication as a FPWD before or at the same time as we publish a FPWD of the DID spec. As chartered, I believe that we owe it to people to be able to understand the requirements driving our specification before or at the same time as they attempt to evaluate the technical specification that implements them.

It's great that we have already adopted an initial use cases document. We need to give it the same care and love as the technical specification, as it's describing why we're doing what we're doing.

[msporny]

Having the Use Cases document is therefore necessary to be able to evaluate the DID specification.

While I agree that having both documents are useful, I disagree that we need to do a FPWD for Use Cases before or at the same time as the publication of the spec. We can merely point to the document from the spec if necessary:

https://w3c-ccg.github.io/did-use-cases/

I would support publishing the Use Cases document as an FPWD ASAP (really, a draft of a document that is intended to eventually become a WG Note). Having read over the entire use cases document recently, it's also very mature for a draft publication by a WG and I'd support publishing the document ASAP.

So, +1 to publishing a WG draft of the use cases document ASAP (but not tying the publication of the did core spec to it).

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.

View the transcript

FPWD (Issue #68)
Daniel Burnett: #68
Ivan Herman: See PR #87 for the FPWD text
Manu Sporny: See also Current FPWD proposal
Daniel Burnett: In this issue, we’re discussing publishing an official “working draft” .. We currently have an “editor’s draft”
… Working draft does not imply group consensus.
… Publishing the first working draft (FPWG) is important since it starts some IPR processes
… To do this, we won’t have an official “vote”, but try to get consensus from the group
… The editors put together a document that would become the FPWD (asides from minor editorial fixes)
… We received one comment with concerns about the document, by selfissued (Mike Jones), do you want to speak about it?
Michael Jones: I raised a concern because since our last call I read the charter. The charter says we will create a Use Cases document with req’s for the technical specification.
… It’s important to have the Use Cases first that explain why we’re doing what we doing
… At TPAC I heard a reference about the Use Cases document, but no time has been spent on the WG to go over UC issues.
… UC document should not be an afterthought. It should inform the technical specification.
… Otherwise we may be condoning neglect of use cases.
Daniel Burnett: “Neglect” may be too strong, but you are right that UC are important and that we haven’t spent time on it yet.
… It’s reasonable to expect that we spend more time on UC upfront before focusing only on the main spec
… The group does need to begin to work on it.
… Topic today is, can we agree to publish FPWD of the core spec.
… We should consider FPWD of UC doc as well.
Michael Jones: See issue #8 in the UC repository
Manu Sporny: I agree UC document is important. I think so far the WG had higher priority items to address.
… Some time has been spent on UC. The current version reflects that, see the reference from the SOTD It’s one of the better UC documents out there compared to other groups.
… I don’t think it should be a gating factor. It’s easy to link from core spec to UC document, so readers are aware of it. This is fine for FPWD to point to documents that are in-process.
… I think people won’t get confused if FPWD of core spec points to in-progress UC document.
… Let’s not gate FPWD by this.
Michael Jones: I disagree with manu’s assertion that UC document is relatively mature.
Manu Sporny: I said “mature for a FPWD”
Michael Jones: I’m reading this with fresh eyes.
… There is a lot of tribal knowledge that is assumed. New readers of the UC document may be confused by not knowing certain things.
… Therefore I raised several issues about things that are not clear to new readers.
… Can we get a gentlemen’s agreement to get to FPWD also for the UC document?
Ivan Herman: I’m also a new reader without the tribal knowledge. I still think we should publish FPWD of the core spec, but FPWD of UC should also be prepared soon (e.g. by end of November)
Brent Zundel: +1 to publishing use cases during November
Daniel Burnett: What I’m hearing is Mike would be okay with publishing FPWD of core spec, if the group has a gentlemen’s agreement to publish FPWD within November and work toward that.
Michael Jones: Agreed
Daniel Burnett: Does anyone object to the intent of the group being publishing FPWD of UC document within November, and working toward that goal (working on Github issues, allocating time on WG calls for this)?
Dudley Collinson: +1 and also happy to participate in use case review
Manu Sporny: I’m trying to formulate a single proposal that addresses both FPWD of core spec and selfissued ‘s requests about UC document.
Ivan Herman: I would prefer three separate, crisp proposals, rather than having everything in a single proposal/resolution.
… We can have them now and vote for them, that’s easier from an admin perspective
Ivan Herman: +1
Daniel Burnett: We already agreed to work on UC document, and we already on Echidna.
… So we should only have to vote on publishing the DID core spec as FPWD
Proposed resolution: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November. (Manu Sporny)
Ivan Herman: +1
David Trang: +1
Ted Thibodeau Jr: +1
Brent Zundel: +1
Manu Sporny: +1
Adrian Gropper: +1
Dudley Collinson: +1
Daniel Burnett: +1
Kyle Den Hartog: +1
Yue Jing (景越): +1
Daniel Burnett: Any suggestions to modify the proposal? Not hearing any. Please respond.
Markus Sabadello: +1
Michael Jones: +1 to trigger the IPR process
Daniel Burnett: Seeing no objections. This is resolved.
Resolution #1: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.
Daniel Burnett: Is there anyone who believes that we must do one of the other two proposals today?
Manu Sporny: We’ll merge and create a static copy for FPWD
Ivan Herman: Formally speaking, we have to wait 1 week before a resolution is accepted.
… I’m aiming for publishing this on Thursday 7th of November.
Daniel Burnett: If there are objections, we encourage people to raise them within 48 hours.
Ivan Herman: As soon as I have the static version, I will start the admin process.
Manu Sporny: Will try to create the static copy today.

[msporny]

FPWD has been published: https://www.w3.org/TR/2019/WD-did-core-20191107/

Closing.