Prepare the VC Data Model v2.0 FPWD publication #894
Conversation
index.html
Outdated
| note: "v2.0", w3cid: 38745}, | ||
| { name: "Gabe Cohen", url: "https://github.com/decentralgabe", | ||
| company: "Block", companyURL: "https://block.xyz/", | ||
| note: "v2.0", w3cid: 0} |
There was a problem hiding this comment.
@iherman, I need Gabe's w3cid value here, please.
There was a problem hiding this comment.
@msporny is it the ID here? https://www.w3.org/users/116851?
If so, 116851.
There was a problem hiding this comment.
That's it! Thank you... only you and Ivan can see it. Adding it now.
msporny
requested review from
decentralgabe,
OR13,
selfissued,
brentzundel,
iherman and
Sakurann
|
Just food for thought... the list of editors is long and that has of course historical reasons. However, it may be better to separate the current editors (who will be responsible for the evolution of the current spec). Wouldn't it be better to have a separate list of "former editors" rather than piling them all up in one place? See, for example, the way we did it for the current EPUB draft spec: |
Yes, agreed that the list is getting very long and takes up quite a bit of space and we should think about doing something about it. I've been thinking about ping'ing the spec-prod team about this and adding a ReSpec rendering feature to render the list of everyone out on a single line. IMHO, the issue w/ splitting things into "Former Editors" is that they don't show up when you cite the document, and in some cases, the former editors have done far more work on the document than the current Editors -- take a minor revision/maintenance release, for example. Fundamentally, ReSpec should probably allow an optional field on which order people should be listed in, where you have people listed in order of contribution across the entire lifetime of the document. That is what the "Editors" list is being used for at present in the VC Data Model spec. If we allowed a "How should this document be cited field" that was separate from the "How the list of Editors, Former Editors, Authors, and Former Authors" appear on this specific revision of the document, that might get us to where we want to be. That said, listing everyone out, in order of contribution level and noting which version they're active with (which is what we do now) is what we have to work with so far. IOW, if we end up in a situation where a new WG can wipe out the people that did 70% of the work from the credits of a document, when the document is a relatively minor revision of a previous document, we end up in a situation that could be viewed as unethical (from a plagiarism perspective). It also doesn't credit people that have done the work appropriately, leading to a sense of unfairness, and ultimately less contributions as a result. |
|
To be discussed on our meeting later today but, for very practical reasons, I do not think the 4th of August publication date is doable. The reason is as follows: the publication of the FPWD must be accompanied by a discussion on how the various TR aliases and redirection would take place for things like https://www.w3.org/TR/vc-data-model/, for that plus '/latest' etc. That must be discussed by the WG (which is fine) but, more to the point, must be implemented by the W3C system team. The best person to do that is Denis Ah-Kang, who is on vacations right now, and back on the 8th. I would propose we should get all ducks in a row (including the director's decision) for the 11th of August. |
Ok, I'll retarget the FPWD for that date. |
msporny
force-pushed
the
msporny-v2.0-fpwd
branch
from
33ab097 to
f080981
Compare
This is now done in f080981. |
|
Having discussed the possible short name setups with @plehegar, here is a proposal for a more general URL set up for the documents on the data model spec. We could (ask our system team to) set up the following URL-s/redirections on the
The logic of the third point is that implementers who are not part of the WG want to rely on a stable specification. Today, that is the 1.1 spec. On the other hand, CR means the specification is, technically, stable; i.e., ie, at that point, it is o.k. for implementers to "switch" to 2.0. The net result of these changes is that external developers could continue relying on https://www.w3.org/TR/vc-data-model for the specification and get exactly what they want, and all other details could be considered an internal cuisine of W3C… cc @plehegar @deniak @caribouW3 to cross check whether my understanding is correct and all this indeed a proper plan to go ahead. P.S. Just as a matter of history, we could also set up a |
|
Yes, it's probably the best option. Note that the WG can decides the version where https://www.w3.org/TR/vc-data-model should point to, whatever the status of the version is. |
|
The issue was discussed in a meeting on 2022-07-27 List of resolutions:
View the transcript4.1. Data model as a FPWD.See github pull request vc-data-model#894. Ivan Herman: Not central but... before we go to FPWD is to decide what the short name is. Kristina Yasuda: It seems uncomplicated to have 'v2' in the short name. Ivan Herman: No, it's not, but we need to ask for it.
Ivan Herman: Yes, the VCWG needs to agree what the short URL is, immutable version URLs etc..
Ivan Herman: It's possible to ask for /TR/vc-data-model-1.1 for the current Rec. Phil Archer: For clarity. The /TR/vc-data-model will imminently resolve to version 1.1 (always to be available at /TR/vc-data-model-1.1).
Manu Sporny: There's a PS. Maybe we should set up a 'version 1.0' URL too.. Kristina Yasuda: Any one against this proposal?. Ivan Herman: A reminder to ourselves. When we do a formal resolution that we're publishing a FPWD, we have to include the short name that we want.
Ivan Herman: Maybe it's the time to remind the group that any formal resolution only becomes set after 5 days. Brent Zundel: Makes proposal.
Kristina Yasuda: We'll leave it to the editors to execute that.. |
The alternative solution would be to point to /TR/vc-data-model/all
It does not appear in /TR/vc-data-model/all, which means that 1.1 is probably considered as |
|
@caribouW3, the https://www.w3.org/2005/05/tr-versions#shortnames does not list the Looking at https://www.w3.org/TR/vc-data-model/all/ today it seems to be an "indirect" link to a table with different versions. Is this its definition? If so, it is indeed useful, but I do not think it is what we are looking for as a URL that non-W3C-savy implementers would be able to use for their own reference. |
|
I am still a bit unhappy with the list of editors. This list suggest that the persons are active contributors to the documents that can be contacted by the community on any editorial aspect of the spec. That is no longer the case and, actually, the affiliations are outdated for some on the list (Kyle, Dan, Brent). I do believe that we should find a way of separating the historical editors from active ones in some way or other. I do understand the citing issue, and we are here to make a choice between two suboptimal choices. (To be clear: this remark is with my staff contact's hat put down!) |
|
Once the merge is done, we should not forget changing the repo's configuration so that the v2.0 branch would be the source of the github pages (as opposed to v1.0 as it is the case right now). I would actually consider renaming 'v2.0' to 'main' (although it is a pain in the neck to do a rename with the number of cloned versions of the repo out there), because it will become a source of bugs if we engage into any kind of github workflow in future (e.g., when we copy an echidna workflow...). |
|
Editorial (no normative statements were modified, but this is a significant major version FPWD release), multiple reviews, changes requested and made, no objections, merging. |
This has been merged, and the default branch is now v2.0 AND the pages are served from the v2.0 branch.
No need to rename v2.0 to main, Github has the concept of a "default" branch, and that's set to v2.0 right now. All previously checked out repos will continue to work, and Github will suggest that people use the v2.0 branch from now on. We will need to tell ECHIDNA to publish from the v2.0 branch, but that should be it. No disruption necessary. :) |
This PR implements the following changes:
Preview | Diff