drafts.w3.org ?

[plehegar]

There is a requests to expose some editor's drafts of documents at a w3.org URL.

We can simply set HTTP proxy on w3.org to the proper places.

For example, as of today, https://www.w3.org/Consortium/Process/Drafts/> is a proxy to https://w3c.github.io/w3process/ .

Most recent request is the vision document: https://www.w3.org/TR/w3c-vision/ -> https://github.com/w3c/AB-public/tree/main/Vision

We could give it something like: https://drafts.w3.org/AB-public/ or https://www.w3.org/drafts/AB-public/

If we go down this path, we'll need some ground rules.

• What sort of editor's drafts would we expect to find there? From documents worked by WGs and IGs? Or would we expect documents worked on by CGs as well?

• Should the format be restricted to HTML documents only or is markdown ok?

[vivienlacourba]

cc: @deniak and @gosko

[frivoal]

Most recent request is the vision document: https://www.w3.org/TR/w3c-vision/ -> https://github.com/w3c/AB-public/tree/main/Vision

We could give it something like: https://drafts.w3.org/AB-public/ or https://www.w3.org/drafts/AB-public/

To clarify, the request is from me, and the actual proxying I asked for was https://drafts.w3.org/AB-public/ or https://www.w3.org/drafts/AB-public/ -> https://w3c.github.io/AB-public/

---

The motivation for this sort of things is to be found in the Process:

All reports, publications, or other deliverables produced by the group for public consumption (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, and backed up by W3C systems such that if the underlying service is discontinued, W3C can continue to serve such content without breaking incoming links or other key functionality.

Given that Editor Drafts are frequently used as the main place where the work is conducted, frequently referred to by external people, and frequently used to solicit feedback, I think that in general, they ought to be covered by this rule, and that proxying w3c.github.io/XYZ/ into drafts.w3.org/XYZ/ (or something similar) would make sense.

What sort of editor's drafts would we expect to find there?

For simplicity, all of those made by WGs and IGs and the AB and the TAG?

From documents worked by WGs and IGs?

Right. With the set-up suggested above, this would allow all EDs, plus whatever WGs and IGs would choose host in their github.io, giving W3C-controlled URLs to any material they chose to promote.

Or would we expect documents worked on by CGs as well? That's a trickier question. I'd be inclined to say yes, but CGs aren't governed by the W3C Process, so the Process rule above doesn't necessarily apply to them. And as W3C has no actual control over the activities of CGs, some objectionable material might end up being shared, without clear recourse. If feasible, I'd still do it, but it's a more difficult quesiton.

Should the format be restricted to HTML documents only or is markdown ok?

Both? Keep it simple, and proxy anything the groups chose to put in their github.io

[deniak]

For TR documents, it shouldn't be too difficult. We could rely on the shortname of the spec, e.g. proxy https://drafts.w3.org// to the actual ED of the spec. The shortname is already unique. The only problem I can imagine is a shortname change which would break the URL using the old shortname unless we also add redirects when a spec changes its shortname.

That being said, I understand we would have additional cases on top of TR documents so in the end, I'm wondering if it wouldn't be simpler to have a dedicated repository where people can contribute to add new drafts.w3.org URLs and our servers will generate a map from that repository to proxy the requests.

[plehegar]

That being said, I understand we would have additional cases on top of TR documents

I think very few documents would be in this case: Process, CoC, Patent Policy. So I'm not sure if we need to include them in drafts.w3.org or simply treat those as special cases that can be dealt with outside of drafts.w3.org. TAG findings have been treated completely separately so they also may not be interested in this.

so in the end, I'm wondering if it wouldn't be simpler to have a dedicated repository where people can contribute to add new drafts.w3.org URLs and our servers will generate a map from that repository to proxy the requests.

Are you proposing that ALL editor's drafts would be contributed to a single repository? That would require dedicated scripts in a lot of repositories. Some of the spec builds are not easy...

[deniak]

so in the end, I'm wondering if it wouldn't be simpler to have a dedicated repository where people can contribute to add new drafts.w3.org URLs and our servers will generate a map from that repository to proxy the requests.

Are you proposing that ALL editor's drafts would be contributed to a single repository? That would require dedicated scripts in a lot of repositories. Some of the spec builds are not easy...

No, just having a file in that repo listing where a path under drafts.w3.org should point to, e.g.:

AB-public https://w3c.github.io/AB-public/
w3c-vision https://github.com/w3c/AB-public/tree/main/Vision
CSP3 https://w3c.github.io/webappsec-csp/

[gosko]

Hi @plehegar, all,

I have long thought that it would be good to rename w3c.github.io to drafts.w3.org – if we did that GitHub would redirect requests for the former to the latter, and people would eventually stop citing URLs on w3c.github.io.

Alternatively we could do some kind of proxying setup but that requires extra work, introduces an additional point of failure, and doesn't create redirects so people would still end up sharing the wrong URLs on occasion.

As far as I can tell we don't have many documents hosted on w3c.github.io for which drafts.w3.org would be inappropriate, but if there are some they could be moved elsewhere, or we could create proxy rules for them from www.w3.org.

If we want to rename w3c.github.io to drafts.w3.org I believe that is a very simple config change in GitHub. (at least it was when I looked a while ago.) But this would be a fairly significant change so it might need further discussion somewhere.

[frivoal]

I don't think there's any need for https://github.com/w3c/AB-public/tree/main/Vision to be proxied anywhere. That's not the ED, that's the source of the ED. The ED is at AB-public https://w3c.github.io/AB-public/Vision, so proxying https://drafts.w3.org/AB-public/ to https://w3c.github.io/AB-public/ would simply give us the ability to do https://drafts.w3.org/AB-public/Vision

[frivoal]

@gosko Yes, that's basically what I think we should do.

In terms of URL persistence, I don't think we'd have to proactively do anything beyond setting up that proxy. Groups would largely be responsible to handle their own content reasonably. But that does gain us the ability, since we control the URL space, to keep serving the content even if some day github went down, became a paid service, got renamed to Y.com, or whatever.

[frivoal]

@deniak If we don't do the wholesale redirect of draft.w3.org to w3c.github.io, a file with that syntax would indeed be pretty easy to manage. There'd likely be a need for someone in the Team to monitor pull requests, rather than allow a free for all, but that seems like a fairly light work load, and a PR would be a simple low overhead way to ask for a new entry.

[gosko]

In terms of URL persistence, I don't think we'd have to proactively do anything beyond setting up that proxy. Groups would largely be responsible to handle their own content reasonably. But that does gain us the ability, since we control the URL space, to keep serving the content even if some day github went down, became a paid service, got renamed to Y.com, or whatever.

+1, my thoughts exactly.

[nigelmegitt]

Sounds good to me to make drafts.w3.org do what w3c.github.io does now, because there are times when the ED is the one you want to point people to.

Care would be needed to make a smooth migration path, i.e.

• how do we redirect people using the old URLs?
• how do we modify the URL section at the top right of the repo home page on GitHub, e.g. for this repo:

• where else have we left pointers to the w3c.github.io links and should we try to do anything about them?

Another question (maybe another issue) is if we can unify the PR Previews and Diffs into the new drafts URL structure somehow? Merely making drafts.w3.org is maybe solving one small problem: seems to me it would be worth a bit of team time thinking about answers to the wider scope of "how do we host and share pre-/TR drafts?" and also how do we make it easy for visitors to the beautiful new w3.org site find those drafts.

[frivoal]

• how do we redirect people using the old URLs?

That doesn't seem like an easy problem, so the sooner we start using good URLs, the better.

• how do we modify the URL section at the top right of the repo home page on GitHub

by clicking here (if you have admin rights over the repo):

• where else have we left pointers to the w3c.github.io links

probably all over the place

and should we try to do anything about them?

progressively, once new URLs are live, as we run into them.

[nigelmegitt]

by clicking here (if you have admin rights over the repo):

Ah, yes, I knew that. I meant how do we fix them en masse across all repos?

[tabatkins]

wholesale redirect of draft.w3.org to w3c.github.io

Wholesale redirect is the way to go imo. That means, for example, that the CSS EDs would be at drafts.w3.org/csswg-drafts/css-whatever-1/, rather than drafts.w3.org/css-whatever-1/.

This is important because it means each group's URL spaces are kept separate. The /TR space is currently kept unique by hand; you have to request a new shortname when publishing a FPWD and it, obviously, can't repeat one that someone else has already used. If we merged all our URL spaces we'd have to adopt similar process for EDs, which would be more bureaucracy at a stage when we can usually avoid having to think about such things.

[plehegar]

by clicking here (if you have admin rights over the repo):

Ah, yes, I knew that. I meant how do we fix them en masse across all repos?

we could create a tool to do so if needed.

[marcoscaceres]

I'm not a huge fan, because I'd personally like to see EDs go away entirely. But I understand that it might not be possible for every group for legacy reasons.

So, In principle support from me to this... but, where possible, we should continue to discourage the use of ED drafts as they are really unnecessary (for groups with that adhere to a more WebApps WG/WHATWG merge policy) - and cause more institutional harm than good, IMO.

[dontcallmedom]

I'm overall supportive, with the following caveats:

• I'm pretty sure there are lots of w3c.github.io URLs that wouldn't be a good fit for drafts.w3.org - with 1100+ repos and very loose regulations on the use of GH pages on the w3c github org, that's bound to be; in terms of not being a good fit - some aren't drafts (e.g. webref data), some aren't from W3C Process groups (a number of CGs have historically been given w3c org repos); the data collected from w3c.json in validate-repos can probably shed some early insights on the situation
• Github doesn't handle redirects when changing repo names IIRC; and repo names get changed quite frequently - if we want to stick to our "Cool URIs don't change" (or in reality, "break"), we'll probably want to put some automation to maintain the redirects defined in https://github.com/w3c/w3c.github.io/

I think using the CNAME option to make w3c.github.io served as drafts.w3.org is the most robust approach, but doesn't leave a lot of leeway (e.g. if we only wanted to serve a subset of the w3c repos there).

[nigelmegitt]

Github doesn't handle redirects when changing repo names IIRC

That would be worth double-checking - I feel sure I once renamed a repo and GitHub handled the redirects automatically.

But the problem we would have is a little different, I think, i.e. we would want w3c.github.io/ links to be redirected as per the CNAME. No idea if GitHub does that.

---

From: Dominique Hazael-Massieux @.> Sent: 31 July 2023 2:45 PM To: w3c/modern-tooling @.> Cc: Nigel Megitt @.>; Comment @.> Subject: Re: [w3c/modern-tooling] drafts.w3.org ? (Issue #110)

I'm overall supportive, with the following caveats:

• I'm pretty sure there are lots of w3c.github.io URLs that wouldn't be a good fit for drafts.w3.org - with 1100+ repos and very loose regulations on the use of GH pages on the w3c github org, that's bound to be; in terms of not being a good fit - some aren't drafts (e.g. webref datahttps://w3c.github.io/webref/), some aren't from W3C Process groups (a number of CGs have historically been given w3c org repos); the data collected from w3c.json in validate-reposhttps://github.com/w3c/validate-repos/blob/main/report.json can probably shed some early insights on the situation
• Github doesn't handle redirects when changing repo names IIRC; and repo names get changed quite frequently - if we want to stick to our "Cool URIs don't change" (or in reality, "break"), we'll probably want to put some automation to maintain the redirects defined in https://github.com/w3c/w3c.github.io/

I think using the CNAME option to make w3c.github.io served as drafts.w3.org is the most robust approach, but doesn't leave a lot of leeway (e.g. if we only wanted to serve a subset of the w3c repos there).

— Reply to this email directly, view it on GitHubhttps://github.com/w3c/modern-tooling/issues/110#issuecomment-1658406722, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGB744R7R7SRUKWYLHW4Q3XS6ZHXANCNFSM6AAAAAA2ZAHJJY. You are receiving this because you commented.Message ID: @.***>

[gosko]

Github doesn't handle redirects when changing repo names IIRC

That would be worth double-checking - I feel sure I once renamed a repo and GitHub handled the redirects automatically.

When repos are renamed GitHub redirects the URLs under github.com but not the GitHub Pages sites.

But the problem we would have is a little different, I think, i.e. we would want w3c.github.io/ links to be redirected as per the CNAME. No idea if GitHub does that.

Yes, if we rename w3c.github.io to drafts.w3.org GitHub would issue redirects for the GitHub Pages site.

There are other things we could do, like creating a drafts.w3.org subdomain on our own systems and proxying to w3c.github.io, or making our own CMS backed by GitHub and publishing the results at drafts.w3.org, but neither of those would result in w3c.github.io getting redirected which is why renaming it in GitHub seems best to me. (if w3c.github.io potentially going away in the future is the problem we're trying to solve)

[gosko]

Github doesn't handle redirects when changing repo names IIRC; and repo names get changed quite frequently - if we want to stick to our "Cool URIs don't change" (or in reality, "break"), we'll probably want to put some automation to maintain the redirects defined in https://github.com/w3c/w3c.github.io/

That's a good point – I see it's also possible to create custom 404 pages, and redirect full paths using javascript.

[plehegar]

If we do a blanket redirect to w3c.github.io, we could filter to allow it only to WGs, IGs, a few selected groups (like AB). This would avoid the whole having to decide which CG should or should not for example.

But, not all groups are under w3c, such as TAG, Immersive Web, or Web Assembly.

[gosko]

If we do a blanket redirect to w3c.github.io, we could filter to allow it only to WGs, IGs, a few selected groups (like AB). This would avoid the whole having to decide which CG should or should not for example.

If we want real HTTP redirects from w3c.github.io to drafts.w3.org we would need to do so for everything on that subdomain, no filtering. If we are OK with some kind of hacky HTML/js redirects those could be more fine-grained. (personally, I don't think that's good enough)

If we rename w3c.github.io to drafts.w3.org and there are repos for which drafts.w3.org is inappropriate we could create URIs for them on www.w3.org using proxy rules. But in those cases both URIs would continue to work (www and drafts) with no redirecting so it would be up to people linking to those resources to choose the right one.

But, not all groups are under w3c, such as TAG, Immersive Web, or Web Assembly.

Those orgs could do the same, using different subdomains.

[fantasai]

I wanted to agree strongly with @marcoscaceres in https://github.com/w3c/modern-tooling/issues/110#issuecomment-1657817892

I'm not a huge fan, because I'd personally like to see EDs go away entirely. But I understand that it might not be possible for every group for legacy reasons.

My suggestion therefore is to use a subdomain like unofficial-work-in-progress.w3.org to make it very clear that documents here should be moving to an appropriate permanent home on w3.org. And do it in a blanket fashion, as others have proposed. If a group complains that their EDs have an awkward URL, then you can encourage them to publish properly more often. :)

(In some cases a WG might want to officially serve a set of documents from github.io; in these cases we should set up additional proxying to a designated URL on w3.org. For example, a WG might want to host its homepage through github.io and serve it through their homepage URL on w3.org. That would make these pages available through two URLs, technically; but we can leave it to the WG to promote the correct set of URLs and/or set up redirects.)

[nigelmegitt]

For example, a WG might want to host its homepage through github.io and serve it through their homepage URL on w3.org.

Good point - I think TTWG already does that, and it'd be bad to break the existing page.

Re EDs going away, we don't have common expectations around the lifecycle of specifications. One pattern that worked well for TTWG recently was to have Editors work away on an ED pre-FPWD, then post-FPWD (i.e. in WD) trigger an auto-publish action on merging pull requests to the main branch, so that the WD is always the up-to-date version and there's no need to bother looking at the ED. I'd recommend this to others.

The EDs fulfilled an important role, and there was no real problem with the w3c.github.io URLs. They still get published by GitHub Pages and are effectively in sync with what's on /TR - nobody has proposed unpublish from github.io when we have a WD but maybe it would make sense.

It's easy enough to set this pattern up for new work, and the work I'm referring to is the experience from one WG. Does it work for everyone? Do people want to change existing working patterns? It's probably worth consulting Editors and Chairs more broadly, or at least pointing out this issue to them, to get wider input - perhaps email specprod@w3 and chairs@w3 @plehegar ?

I know in the past some Editors have been quite precious about keeping "their" working space. That's also something I'm not keen to maintain, because I think WGs should take collective ownership of their output rather than delegating to a small set of "wise individuals".

But the idea of forcing people onto a subdomain with an uncomfortably long name including the word "unofficial" is taking it too far in my opinion, at least before we have a broad set of views. WG work is in some sense official, if it's within the scope of a Charter, even if it has not yet got consensus from the WG or the W3C.

[fantasai]

WG work is in some sense official

It is colloquially, but also it's not. None of it is covered by the Patent Policy, for example... It might be official in the eyes of the WG, but it isn't from a W3C perspective.

CSSWG has a similar pattern for pre-FPWD EDs, fwiw. I'm ok with putting them under an uncomfortable name because they should be migrating to FPWD quickly. FPWD isn't a seal of approval, it's nominally the "first public working draft" -- the first draft that you want people outside your WG to look at. I think we often (and I include the CSSWG in this for sure) don't publish early or often enough, and I think nudging groups in that direction is maybe a good thing. :)

[nigelmegitt]

It is colloquially, but also it's not. None of it is covered by the Patent Policy, for example... It might be official in the eyes of the WG, but it isn't from a W3C perspective.

That's too narrow a definition of "official" for me. WG members working on a document approved by AC via the Charter should be considered official, even if the result of that work eventually (and officially) gets abandoned as the Process allows for. "Official" is not a synonym for "complete and approved by W3C".

But maybe this is a side track - I'd argue that what's more important is that we communicate well with readers of the document so they know where the right one is for them to read.

URLs do communicate something but they're a blunt tool. Maybe a better alternative is to require, for each specification, that the controlling WG assigns a "current main version" status to exactly one URL, and for any other version available at a different URL, a banner appears directing the reader that they're not looking at it, with the option to keep going anyway, or traverse to the current main one.

We do that anyway for old dated versions, so why not extend to EDs when there's a WD available, if the "auto-publish on PR merge" pattern is used? If groups really want to keep EDs as the "current main" then they would have to accept a banner on their WD, which I would argue isn't a great look for them.