Open ianbjacobs opened 8 months ago
ianbjacobs
commented
8 months ago @csarven, once the reports have been reformatted, it would be great to register them in the W3C CG Report system by way of the "publish" button that appears on the CG's home page when you are (1) logged in and (2) chair of a CG. For more, see: https://www.w3.org/community/about/faq/#how-do-we-publish-a-report
Thanks!
csarven
commented
8 months ago Thanks @ianbjacobs ! Am/we're aware.
Short response: Going forward, the CG will produce CG-DRAFT/FINAL reports as you recommend as well as per Solid CG charter.
Longer response:
The latest published versions (what you see published under solidproject.org/TR/ ) and the deliverables referred by the proposed Solid WG charter have been using the Solid Process (which is no longer applicable to the CG). This is only one part of the reason why Solid CG hasn't produced a CG-DRAFT/FINAL. Going forward, the CG will follow its CG charter (became effective 2023-09-01), which is aligned with W3C's processes and recommendations.
To the best of Solid CG's and W3C contacts' ( @pchampin @rigow ) knowledge:
Happy to be corrected on anything above. And happy to hear any additional insights you can offer.
Again, happy to produce CG-DRAFT/FINALs (in particular proposed deliverables of the WG charter) and follow up with the publication process.
We will also follow-up with updating CG's Contributing Guide to reflect any remaining changes related to publication of documents/reports.
Lastly, I understand the differences between what can be practised, required, or prohibited by W3C in a CG (and elsewhere) may be confusing to some or even many. I can only recommend that existing CG requirements, W3C Process, and other guides are updated to further help minimise these confusions for anyone, and to better communicate expectations. If you'd like me/us to follow-up on this with you / W3C Team in another thread/repository, happy to do so.
ianbjacobs
commented
8 months ago Hi @csarven,
CGs are not prohibited from producing documents that are not CG-DRAFT/FINAL, with any status, license, at any location, or using any particular stylesheets/scripts (=we're aware that they're not or equivalent to W3C "Community Submissions").
That is also my understanding.
Deliverables of a WG charter or proposed specifications are not required to have a CG-DRAFT/FINAL status in order for them to be accepted in Recommendation/Note/Registry Tracks.
That is also my understanding (but not directly relevant to the current thread about CG Report requirements).
On a related note, the common understanding is that a "Working Group will not adopt new proposals until they have matured through the [CG] or another similar incubation phase.".
Here is what the Advisory Board wrote in 2016 [1] on that topic: "Strongly Recommended: Charters do not list specs as deliverables, and WGs do not publish FWPDs, until there is rough consensus across stakeholders that the spec solves a real problem, is likely to be implemented, and is likely to be used on the Web. This consensus could emerge from an incubation phase in WICG or another CG, or in a WG that has an established culture of taking and vetting suggestions from its public mailing list."
[1] https://www.w3.org/Guide/standards-track/#criteria
We have taken steps to make sure that copyright/licensing in the CG charter will remain compatible with W3C policies and have acknowledged that agreements made through CG-DRAFT/FINALs will better help to transition works from the CG to a WG.
Our FAQ [2] includes this:
Q. Can I make it a condition of joining a Community or Business Group or publishing a Report that people must agree to licensing terms beyond the CLA/FSA? A. No.
Is the expectation that people cannot join the Solid CG unless they agree to the terms and conditions of the charter?
Lastly, I understand the differences between what can be practised, required, or prohibited by W3C in a CG (and elsewhere) may be confusing to some or even many. I can only recommend that existing CG requirements, W3C Process, and other guides are updated to further help minimise these confusions for anyone, and to better communicate expectations. If you'd like me/us to follow-up on this with you / W3C Team in another thread/repository, happy to do so.
We welcome suggestions on team-community-process@w3.org. Thank you!
michielbdejong
commented
2 months ago @ianbjacobs the list of draft reports I filled in on https://www.w3.org/community/solid/ during our meeting today was a copy of https://solidproject.org/TR/#work-items
But since then I got a message from @VirginiaBalseiro saying this list is incorrect and not conforming to https://www.w3.org/community/reports/reqs/. I was also unaware that this had been an open issue since October.
As we discussed there is an 'add' button but no 'remove' button. Can you please remove the list again? Sorry for the hassle!
csarven
commented
2 months ago I will PR a CG-DRAFT (and eventually FINAL) of the Solid Protocol based on ED. I have the CG-DRAFT ready but was waiting on the possible resolution of some of the items in the last milestone if the Group deemed them to be ready. There is no showstopper to have a CG-DRAFT of what we have, and I think we can go ahead with it. I can PR in the next week or so (keeping in mind travels). We (CG) can perhaps pick it up on 2024-05-08 ( @VirginiaBalseiro ).
We can publish other Work Items as CG-DRAFT/FINALs once they're ready and agreed upon.
ianbjacobs
commented
2 months ago Hi all,
If these are indeed reports of the CG, then it is important that they adhere to the CG report requirements [1], including the copyright statement, use of logos, boilerplate text, etc. Let me know how I can help on this.
Regarding the link from the CG’s home page, I think we can leave them in place since the more important bit is that the spec styles be updated. (And I’m assuming the URLs will point at the updated drafts.)
Thank you,
Ian
[1] https://www.w3.org/community/reports/reqs/ [2] https://www.w3.org/community/solid/
On Apr 25, 2024, at 9:57 AM, Sarven Capadisli @.***> wrote:
I will PR a CG-DRAFT (and eventually FINAL) of the Solid Protocol based on ED. I have the CG-DRAFT ready but was waiting on the possible resolution of some of the items in the last milestone if the Group wanted them in there. There is no showstopper to have a CG-DRAFT of what we have, and we can go ahead with it. I can PR next in the week or so (keeping in mind travels). We (CG) can perhaps pick it up on 2024-05-08. We can publish other Work Items as CG-DRAFT/FINALs once they're ready and agreed upon. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
-- Ian Jacobs @.***> https://www.w3.org/People/Jacobs/ Tel: +1 917 450 8783
VirginiaBalseiro
commented
2 months ago @ianbjacobs the list of draft reports I filled in on https://www.w3.org/community/solid/ during our meeting today was a copy of https://solidproject.org/TR/#work-items
@michielbdejong can you clarify what "our meeting" is referring to?
csarven
commented
2 months ago @ianbjacobs I think we already covered this earlier in the issue and elsewhere.
Just for clarity for those not heavily involved in the CG or who need a summary:
Our process prior to the Solid CG Charter didn't include publishing W3C CG Reports. The documents that are currently referenced from Solid Work Items are not "W3C CG Reports" as it stands but we're transitioning to it. We have documents with status along the lines of editors/unofficial drafts, living documents, notes, and lowercase technical reports - was never intended to be conflated with W3C Technical Reports, not hosted w3.org, not using W3C logo, not implying W3C endorsed, among other things to say the least.
@ianbjacobs :
https://solidproject.org/TR/{YYYY}/{shortname-YYYMMDD}) would qualify for CG-DRAFT, but I'm not sure how to approach the others in a fair way that both reflects their maturity as well as group's consensus.Related:
ianbjacobs
commented
2 months ago @VirginiaBalseiro, @michielbdejong and I were chatting about CGs in the context of another group.
ianbjacobs
commented
2 months ago @csarven, @VirginiaBalseiro, and @michielbdejong,
If these documents are not (yet) CG Reports, please do not indicate that they were published by the Solid Community Group. Instead, please indicate which individuals drafted them. Because these documents are not CG deliverables, please remove mention of the CLA. (Indeed, you refer to the MIT license in the documents that I looked at.)
In other words: these are either CG Reports published by the group under the CLA and consistent with the requirements for CG Reports, or they are some other kind of document that has no relationship to any W3C process or group.
Regarding your questions above:
elf-pavlik
commented
2 months ago CG drafts can be living documents; they do not need to be immutable (but can be).
Most Solid drafts had versioned snapshots published as "WD" and living documents available as "ED". Many documents use Bikeshed, which seems only to have two options—CG-DRAFT and CG-FINAL. I understand that no templates equivalent to ED and WD are available for Community Groups. Until finalized, should they use the CG-DRAFT template? We should still be able to have immutable releases similar to "WD" tagged with 0.x version numbers.
Linking from the 0.x tagged immutable version (~WD) to the latest version on the main branch (~ED) might be slightly nuanced since the link would commonly be labeled Editor's Draft. Is there a recommended term that could be used in CG drafts to label that link?
ianbjacobs
commented
2 months ago I am still getting up to speed on the status and plans for these documents. But if a document is not yet a Draft (or Final) CG Report, it should not claim to be the product of the CG (and not use the CG styles, license, etc.). If a call would be useful, let's find time next week.
VirginiaBalseiro
commented
2 months ago If a call would be useful, let's find time next week.
That would be very useful, thank you! A number of us will be attending Solid Symposium next week and thus unavailable, but would you be able to join our weekly CG call on Wednesday May 8th at 14:00 UTC?
ianbjacobs
commented
2 months ago Yes I can join that call (please email me the call info). Thanks!
csarven
commented
1 month ago Quick status update:
I have the CG-DRAFT ready but decided not to PR yet. Traveling today. I will do it this week in a calmer moment/space. More details will be in the PR that we can review. A quick FYI for now:
https://solidproject.org/TR/2024/{YYYYMMDD}-protocol).ianbjacobs
commented
1 month ago Hi Virginia,
I am not having luck joining the call here; https://www.w3.org/events/meetings/a810b828-7a85-47b8-8a6d-2359a491a7f7/20240508T140000/
Ian
On Apr 26, 2024, at 10:21 AM, Virginia Balseiro @.***> wrote:
If a call would be useful, let's find time next week. That would be very useful, thank you! A number of us will be attending Solid Symposium next week and thus unavailable, but would you be able to join our weekly CG call on Wednesday May 8th at 14:00 UTC? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
-- Ian Jacobs @.***> https://www.w3.org/People/Jacobs/ Tel: +1 917 450 8783
elf-pavlik
commented
1 month ago You were an hour too early. It will start 20 min from now.
elf-pavlik
commented
1 month ago As for the Editor's Draft at https://solidproject.org/ED/protocol , that's also being updated to better clarify (e.g., in copyright, Status of this Document) that it is not a CG report and of course continue to not imply that W3C is endorsing it. The document will live on as is, and we can cut CG-DRAFT/FINAL(s) from it.
What reason do you see for the 'ED' not to be a CG draft? I'm looking at
and they both seem to use the 'CG-DRAFT` template; I also notice the Latest published version and Latest editor's draft terminology. I also noticed that the 'ED' has UNOFFICIAL watermarks.
ianbjacobs
commented
1 month ago Thanks again for including me in today's meeting. Here's a quick summary of my thoughts:
I am happy to continue to contribute to this discussion. Thanks!
csarven
commented
1 month ago What reason do you see for the 'ED' not to be a CG draft?
That might be begging the question =)
The initial intention was to not have our ED/protocol imply anything W3C labelled/endorsed, unless it has to do with CG-DRAFT. Right now ED/protocol uses the W3C ED stylesheet and the SotD is a bit mangled. It either needs to completely drop off association with W3C or as you seem to be asking about:
Our ED/protocol should only be unofficial CG-DRAFT. That'd be same as https://w3c.github.io/rdf-star/cg-spec/editors_draft.html AFAICT.
As I see it, if "unofficial" CG-DRAFT serves as a draft for us along the lines of what we've intended at ED/protocol (editor's draft), that'd be fine. When we want to make it "official", we propose CG-DRAFT (without unofficial watermark once W3C approves) updating our TR/protocol (and "this version" referring to https://solidproject.org/TR/2024/{YYYYMMDD}-protocol, which is similar to https://w3c.github.io/rdf-star/cg-spec redirecting to latest CG-DRAFT at https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html ).
As mentioned earlier, CG-DRAFT doesn't have to be at TR/protocol (and could be under w3.org). However, CG-FINAL will be published under w3.org (e.g., https://www.w3.org/2021/12/rdf-star.html ) if need be.
Aside (speaking only based on my own understanding/observation):
As it currently stands at W3C, there is no ED or UD for CGs. While some CGs use(d) ED/UD - possibly because of process and tooling confusion, as well as nothing particularly prohibiting their use - they are incorrect and need to change. As Ian also mentioned above, CGs are only expected use CG-DRAFT/FINAL and to not communicate other kinds of document types/statuses found at W3C (see also https://www.w3.org/standards/types/#x1-summary ) or imply association with W3C.
So, I'd much prefer to have ED/protocol be an unofficial CG draft and remain that way rather than something else.
The W3C tr-pages issue that I've mentioned earlier highlighted that unnecessary ED/UD constraint at W3C (as I see it, IANAL) but that's not something for debate here. It is an open issue there, for W3C to consider acknowledging ED/UD for CGs because it is something used out there, and CGs can still publish CG-DRAFT/FINAL. But at this point, I don't care if unofficial CG-DRAFT essentially serves a similar purpose pragmatically speaking.
elf-pavlik
commented
1 month ago I don't think that UNOFFICIAL CG-DRAFT is defined somewhere. I just saw that some drafts have a UNOFFICIAL watermark used in their templates. Since many Solid drafts use bikeshed I would like to have clarity on which of the available templates should be used
I think all drafts should use CG-DRAFT, which seems to add the UNOFFICIAL DRAFT watermark, as seen here: https://solid.github.io/data-interoperability-panel/specification/
There is also UD, but it doesn't seem to be intended for CGs, as seen here: https://solid.github.io/data-interoperability-panel/primer/application.html
Does anyone see a problem with using the CG-DRAFT template for all CG work items, whether it is the latest published version (tagged/timestamped release snapshot) or the latest editor's draft (auto-generated from the main branch)? For me, this is the priority to answer because we still have time to figure out if and when to promote selected drafts to CG-FINAL.
For the Solid community status, we discussed what signals the group wants to send to the community during the call.
As I understand the maturity levels working groups use, reaching CR signals that the draft is primarily stable and ready for implementation. Many people find it problematic to go that far without actual implementation experience. Solid takes a more agile approach and strives for continued implementation feedback; there is already an advanced test suite for various product classes. Having versioned releases allows better communication with developers and clarity on which draft and version are being implemented.
For example https://communitysolidserver.github.io/CommunitySolidServer/latest/usage/notifications/ references a tagged 0.2 release of Solid Notifications Protocol.
Another example where we initially failed to do that is https://solidproject.org/TR/oidc We had yet to tag a release before it was implemented, as we needed to make a significant change and tagged it 0.1 after that change. This made communicating conformance much more challenging for implementations which so far only implemented the pre-0.1 version.
csarven
commented
1 month ago I would like to have clarity on which of the available templates should be used
W3C Team / Ian can correct me but as per https://www.w3.org/standards/types/#x2-1-w3c-community-group-report-or-w3c-business-group-report and https://www.w3.org/community/reports/reqs/ and irrespective to the tooling or environment that's used to create the report, the report needs to apply the CG-DRAFT template, styles, and include certain content (e.g., copyright, SotD).
The W3C stylesheet for CG-DRAFT by default applies the unofficial watermark, and the unofficial watermark is removed when the no-watermark word is a value of <body class> - I presume once approved by W3C Team.
https://solid.github.io/httpsig/ is already unofficial CG-DRAFT (using Respec).
I suggest all applicable Solid CG work items should first transition to (unofficial) CG-DRAFT. Any work item that is deemed to be mature to be "official", we (CG) can make a request to W3C Team Process - something we currently have in the pipeline for some specs any way.
Solid CG's use of versioning is already compatible with CG Report Requirements in the Copyright line: "REPORT NAME/VERSION". That is, the reports will say CG-DRAFT/FINAL as well as can mention the specific version. This helps to distinguish different CG-DRAFTs before a CG-FINAL.
elf-pavlik
commented
1 month ago The W3C stylesheet for CG-DRAFT by default applies the unofficial watermark, and the unofficial watermark is removed when the
no-watermarkword is a value of<body class>- I presume once approved by W3C Team.
@ianbjacobs During the meeting, I understood that CG chairs can use the CG system to request CG-FINAL status. At the same time, I'm unclear about how this process of W3C Team approving a regular CG-DRAFT works. I was under the impression that CG can publish any CG-DRAFT without an approval step, it only needs to follow https://www.w3.org/community/reports/reqs/
ianbjacobs
commented
1 month ago @elf-pavlik, the Team does not play any role in a group's decision to publish. I am joining this conversation to help with the requirements.
elf-pavlik
commented
1 month ago Since both ReSpec and Bikeshed add that UNOFFICIAL watermark, I assume this is required for any CG-DRAFT. I understand it is possible to override it and remove that watermark, but when is it appropriate to do it?
Looking again at
The Latest editor's draft does have the UNOFFICIAL watermark, while the Latest published version does not have any watermarks.
@ianbjacobs, is there official guidance on how the UNOFFICIAL watermark is expected to be used on a CG-DRAFT document?
ianbjacobs
commented
1 month ago @elf-pavlik, I believe this watermark is by design.
csarven
commented
1 month ago The "W3C stylesheet for CG-DRAFT" being https://www.w3.org/StyleSheets/TR/2021/cg-draft
elf-pavlik
commented
1 month ago If the watermark is required, disabling it isn't a valid option. Does it mean that, for example, https://w3c.github.io/rdf-star/cg-spec doesn't meet the CG-DRAFT publishing requirements due to a lack of the UNOFFICIAL watermark?
ianbjacobs
commented
1 month ago @elf-pavlik, that appears to be a Final Report and so the expectations may be slightly different.
csarven
commented
1 month ago elfPavlik, AFAICT, i.e., don't quote me, both watermark and no-watermark is available from the CG-DRAFT stylesheet, so it is indeed there by design. What I'm concluding from that is that the no-watermark is applied when CG is done/ready/okay to publish the CG-DRAFT.
This is part of the clarifications that I'm seeking in https://github.com/w3c/tr-pages/issues/102 as part of the W3C documentation.
Ian, AFAICT, that is the CG-DRAFT. CG-FINAL is at https://www.w3.org/2021/12/rdf-star.html (and that also has the no-watermark word in body class.)
elf-pavlik
commented
1 month ago https://w3c.github.io/rdf-star/cg-spec
Ok, now I see that it says Final Report but uses the Draft Report logo
https://www.w3.org/2021/12/rdf-star.html
This one uses both the Final Report text and the Final Report logo.
csarven
commented
1 month ago Oh I stand corrected re https://w3c.github.io/rdf-star/cg-spec -> https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html which is indeed CG-FINAL as far as the content is concerned. That is indeed confusing with the logo. The logo bit was probably a mistake. See also https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Frdf-star%2Fcg-spec%2F2021-12-17.html&doc2=https%3A%2F%2Fwww.w3.org%2F2021%2F12%2Frdf-star.html which seems to be essentially identical.
elf-pavlik
commented
1 month ago During the call, we discussed that CG-FINAL can be updated as much as needed. Is there any disadvantage to maintaining the editor's draft as CG-DRAFT and updating CG-FINAL to the latest tagged release?
I see that FINAL terminology is quite confusing here, but it seems like a valid option to use it as the Latest published
ianbjacobs
commented
1 month ago @elf-pavlik, we intended "Final" to mean "he group intends for this to be referenced as a stable document (notably for IPR reasons)." If you intend to use it to signal that this publication is a stable reference, then Final seems appropriate.
elf-pavlik
commented
1 month ago Could you please clarify what stable entails?
If we draw parallels to maturity levels in a working group, can each Working Draft be considered stable, or are only the Candidate Recommendation and the later stages considered stable?
ianbjacobs
commented
1 month ago "Stable" here is intended to create a snapshot for IPR reasons principally. It is also intended as a signal that this particular instance is the culmination of some effort (and, for example, at this point the group would like to hand it to a Working Group). I think that if there's a constantly evolving document and the group wants to say to the community "we are still very much working on this document" then Draft is a better fit.
elf-pavlik
commented
1 month ago Thank you, @ianbjacobs, for the very helpful clarifications.
My conclusions are following.
-2024-05-09) as well as all the editor's drafts, which simply reflect the latest state of the main branch in the repo.Keeping in mind that some possible further clarifications could come via https://github.com/w3c/tr-pages/issues/102
csarven
commented
1 month ago After re-re-revisiting, comparing tool outputs, checking CG-DRAFT reports out there, reviewing style guidelines,... my current understanding is that CG-DRAFT only comes with a watermark and the no-watermark is an isolated case in https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html (besides the logo being stuck on CG-DRAFT while content saying "Final"). I do not know if the use of no-watermark was allowed by W3C Team, or an error / oversight somewhere.
So, by default, whatever the CG wants to communicate externally should be the versioned release (as per CG Guidelines) of a CG-DRAFT, e.g.:
https://solidproject.org/TR/{YYYY}/{shortname}-{YYYYMMDD}
and possibly the "latest published version" if only one reference is preferred:
https://solidproject.org/TR/{shortname}
For specs that (may likely) continue to be available from github io (GH pages) and not make their way into the solid/specification repo to be published under solidproject org's TR/ , they need to stay as CG-DRAFT's with the unofficial watermark.
In cases where we (CG) has an "ED" of a spec, e.g., https://solidproject.org/ED/protocol , https://solidproject.org/ED/qa , in addition to some snapshot, I think there are two routes:
Options 1:
Option 2:
From my point of view, option 2 is marginally simpler and doesn't conflict with W3C's requirements because it is published on solidproject.org - anyone can say anything about anything applies - and w3.org's CG or Report pages won't be linking to the ED any way when the actual CG-DRAFT is available / endorsed from the URLs that I mentioned above. I'm fine with option 1 too if W3C insists - it requires minor changes if/when we want to create a new CG-DRAFT out of it.
We can reflect these things in the CG Contributing Guidelines once agreed.
Any way, I'm all ears if there are other / better flows.
csarven
commented
1 month ago @ianbjacobs , I've done the option 1 above for now (see below for details). If option 2 is also acceptable or another option is preferable, please let us know.
Can you please have a look at this CG-DRAFT report (just published following https://github.com/solid/specification/pull/651 ) and confirm that it conforms to the W3C CG-DRAFT Report requirements:
"This version" and "Latest published version" are borrowed from W3C terminology, so you can expect "this version" to be the immutable version (for all intents and purposes, similar to the way W3C allows revising class-1 changes to Recs) after publication and "latest published version" to be mutable (content updated whenever there is a new version).
If not, can you please let us know for any changes (either as a separate issue or in this issue would do), thanks.
I have also updated the "Editor's Draft" of Solid Protocol:
I have it set to use the W3C Base stylesheet: https://www.w3.org/StyleSheets/TR/2021/base.css and I have updated the text (copyright, sotd, etc.) to not state that it is a W3C CG report or endorsed by W3C in any way. I want to emphasise again that this "ED" is not same as W3C ED besides using the same terms: "editor's draft".
If that is acceptable as well, we can then make sure to keep our CG-DRAFT reports and our EDs as visibly and content wise separate (not touch on "W3C") without being a bother to anyone. We (like many other CGs) have some need to publish some sort of a versioned release (e.g., CG-DRAFT, vX.Y.Z) for some of our documents as well as having an ED of sorts for internal, WIP, day-to-day stuff. Some of this discussion is also touched on https://github.com/w3c/tr-pages/issues/102
Thanks!
ianbjacobs
commented
1 month ago cc @dontcallmedom
ianbjacobs
commented
1 month ago Hi @csarven,
First, thanks for working on this. The CG-DRAFT report looks good with respect to report requirements.
For the Editor's Draft I have some minor questions. The status section states "This report was not published by the Solid Community Group." I wasn't certain about consistency of that statement with other metadata and so would like to hear your thoughts. Specifically:
Thanks again for working together on this.
elf-pavlik
commented
2 weeks ago Could someone please take a look at the updated https://solid.github.io/solid-oidc/
The approach is that any version will be a CG-DRAFT as an official work item of Solid CG. There will be tagged releases with snapshots and permalinks, all of which are just versions of the same CG-DRAFT. To avoid any confusion, I won't use Editor's draft terminology at all. Also, since this repository already uses a pull request workflow with reviews to introduce normative changes,
The linked document uses a CG-DRAFT template provided by Bikeshed. @CxRes suggested that Solid CG CG Draft shouldn't use the W3C logo, but I think this needs to be clarified since that template uses the logo by default.
csarven
commented
2 weeks ago @elf-pavlik That, irrespective to whatever tooling you're using, doesn't conform to https://www.w3.org/community/reports/reqs/ , so you'll need to update the copyright and SotD.
Removing "W3C" stuff was only in the case of CG communicating anything but CG-DRAFT/FINAL reports. So, CGs should only publish / communicate CG-DRAFT/FINAL.
elf-pavlik
commented
2 weeks ago To have SotD auto-injected by bikeshed, I may need to PR to bikeshed. This way, all SolidCG cg-drafts will have the same SotD. I will probably base it on https://github.com/speced/bikeshed/blob/main/bikeshed/spec-data/readonly/boilerplate/fedidcg/status.include
As for copyright, it indeed looks different from what I see in https://fedidcg.github.io/FedCM/
Copyright © 2024 the Contributors to the Federated Credential Management API Specification, published by the Federated Identity Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
I'm asking on bikeshed matrix channel how we can have something similar automatically added in all Solid CG drafts.
ianbjacobs
commented
2 weeks ago @elf-pavlik, I think one can use a copyright.include (but I am not a bikeshed pro.)
elf-pavlik
commented
2 weeks ago Thank you, @csarven and @ianbjacobs. I have created a PR for bikeshed to include default copyright and SotD for Solid CG drafts and final drafts.
Once it is merged and the updated bikeshed is released, I will update all the 12 CG drafts that use bikeshed to render with that default text.
EDIT: Preview available on https://elf-pavlik.github.io/solid-oidc/
elf-pavlik
commented
1 week ago https://solid.github.io/solid-oidc/ has been updated to use text from https://www.w3.org/community/reports/reqs/
Bikeshed has the Solid CG included in https://github.com/speced/bikeshed-boilerplate/tree/main/boilerplate/solidcg
I'm in the process of updating all the remaining bikeshed-based drafts. After that I will also update the script to cut versioned releases.
Are there any outstanding TODOs in this issue, or can we close it?
CxRes
commented
1 week ago I would like to express serious reservations about the changes to the copyright statement in Solid TRs that is being adopted!
I find it extremely strange how work items can be "released" under the CLA. The CLA is not a licence in the traditional sense. The CLA is an agreement between "I" the contributor and "you" The Solid Community Group (and presumably other contributor in it). In particular, "you" cannot be interpreted as citizens of world or at least Berne convention signatories. Specifically, the statement says nothing about the rights that the Solid Community Group accords to the general public to use these specifications. It follows that without a license grant, the general public has no rights to "copy" these specifications.
While I cannot speak for others, I had signed the CLA, and thus, waived my own rights over those contributions, under the assumption that my contributions will be permissively licensed by the Solid CG, i.e., my contributions will be available to the world at large, not just to a CG or its other contributors or the W3C. I expect the Solid CG to honour that expectation.
Therefore, I would urge the statement be redrafted. If the statement is a W3C requirement, then W3C needs to seriously revisit them, not Solid CG be asked to release work items under a more restrictive license. I have no objection to stating that contributions were made to it under the CLA and thus Solid CG has copyrights to these contributions, but it must explicitly state how Solid CG makes the document in question available to the world at large.
elf-pavlik
commented
1 week ago @CxRes would this license work for you? https://www.w3.org/copyright/document-license/
I have no clue how all that legal stuff is supposed to work. I recall when we had a call with Rigo, there was a request to adjust the licence to allow reuse code snippets without need for a notice. TBH, it doesn't seem Solid specific, so if some clarifications come out, they should probably be shared outside of this issue and this CG.
CxRes
commented
1 week ago would this license work for you? https://www.w3.org/copyright/document-license/
It would have, until recently. But it has a strange line in it:
HOWEVER, the publication of derivative works of this document for use as a technical specification is expressly prohibited.
This I feel is not suitable at the CG stage, where we should be encouraging people to experiment with new ideas.
So now, I much rather prefer this: https://www.w3.org/copyright/software-license-2023/
Hi all,
In looking at a sample Solid technical report such as: https://solidproject.org/TR/protocol
I would like to draw the CG's attention to our CG Report requirements: https://www.w3.org/community/reports/reqs/
Among them notably, we have style requirements (to help people understand the status of documents) and copyright statement requirements (per the CG policies), etc.
I'd like to request that the CG make appropriate changes based on these requirements. Don't hesitate to contact me on team-community-process if you have questions.
Cheers, Ian
[1] https://www.w3.org/community/about/process/summary/