Re: [csswg-drafts] Replace the https://drafts.csswg.org/ backend (#7500)

> 1. In addition to serving drafts.csswg.org the same application also serves drafts.fxtf.org and drafts.css-houdini.org

A replacement served using the https://andreubotella.com/csswg-auto-build/ setup can do that too.

> 2. It also serves the Shepherd spec anchor/link database and spec related parser (used by Bikeshed and Respec), which is auto-updated on each draft commit.
> 3. It also serves api.csswg.org/bikeshed and keeps its copy of the spec anchor/link database up to date on each draft commit.
> 4. In addition to generating individual drafts when they are committed, it regenerates all other drafts when the anchor/link database gets updated to keep all the cross references up to date.
> 5. In addition to serving all the current versions of the drafts, it keeps all the historical versions and can serve the generated specs at any point in their history via a dated URL (and exposes the history in the UI from the home page).
> 6. In addition the server handles the CSS Test Harness which is still used to generate CR exit criteria and keeps the test suites built and the test harness synced with the spec anchor database.

All of those requirements are separate from the requirement for users to be able to reliably read drafts.csswg.org specs.

From the fact that current backend uses a single system to do those 5 other things in addition to serving the CSS specs themselves, it doesn’t necessarily follow that any system for serving the CSS specs for users in the wider community to read, the system must also do those other 5 things too. It’s not axiomatic that all those things must be coupled together in the same way they are now.

The record of users reports we have is overwhelming just from users trying to read CSS specs — as evidenced by the almost-one-year worth of user reports at https://github.com/w3c/csswg-drafts/issues/6528. I can recall seeing one or two reports elsewhere (I think just in the WHATWG Matrix room) about api.csswg.org/bikeshed and maybe the spec anchor/link database not working — but I can’t recall ever seeing reports from actual end users about any of those other 5 things not working.

That would seem to suggest that we should try, if we can, to optimize for the known needs of end users in wider community. And if having a single system that does 5 other things too has the effect of making things less reliable for end users who just want to read the CSS specs themselves, then that would seem to suggest we consider if we can decouple the just-serve-the-CSS-specs-themselves-for-end-users need from the rest of things.

It seems worth noting here that there do in fact seem to be a lot of end users who do actually want to just read the CSS specs. Part of that is because every CSS article in MDN has a link to the relevant parts of the CSS specs that define each CSS feature documented in MDN. Also, Stack Overflow questions and answers about CSS features also sometimes (maybe often) include links to the relevant parts of the CSS specs.

Users coming in from those places don’t have need for the other 5 things listed out above. Instead they just want to read some part of a CSS in order to solve some immediate problem they’ve run into, or to find an answer to some question.

>  7. The funding to update the server has already been approved by a sponsor and we're just waiting for final paperwork before the work begins (hopefully within the next few weeks).

I raised this issue without knowing that — because until it was stated in the comment above, I hadn’t heard that.

But I don’t believe the fact that there’s a sponsor on the horizon relieves us from responsibility from looking in detail at the actual end-user needs, and based on those needs, trying to make an objective assessment of what could be the best way to address those needs.

>  8. All the source for the server is open, and always has been. Anyone could have stepped in to help at any point, this hasn't happened since 2014 when the draft server first went online.

One extreme way to interpret that is the other stakeholders in the wider community are lazy and ungrateful and have for all this time just been sitting around waiting for someone else to fix the problem for them for free.

But some other possible ways to interpret that is that although the source for the server is open, and always has been, maybe very few people are even aware of that fact, and maybe very few people have any idea where the source might even be — until it was stated in the comment above, I personally certainly wasn’t aware of it. And even at this point, I don’t even know where the source for it all might be.

But along with that, even if others were to know where that source is, in order to try to help with through code contributions, they’d need to also know how to test their changes, and how the changes get deployed, what exactly it’s served from, etc.

But on top of all that, in order for anybody else to try to make fixes to the code or deployment, they’d first need to know what’s broken: What specific part of the code causes the system to get wedged 3 or 4 days out of each week? Or if it’s not part of the code, what part of the deployment system or the server ecosystem needs to be changed?

I don’t think others in the community have any answers to those questions at this point (I certainly don’t know the answers myself). And without knowing some of that information, how could contributors even start to try to help fixing it?

> If you think starting something new will get more people involved, I'd like to see some evidence.

https://github.com/andreubotella/csswg-auto-build is evidence at least of a starting point that seems likely to allow more people to step in when the need arises. One way to interpret the fact it so far has only one contributor would be to assume that nobody else cares about it. Another possible way to interpret it is that it’s so far been working reliably enough every day that nobody else has yet needed to step in to help work on it.

One fact I can add here is that because the unavailability of drafts.csswg.org was regularly causing the https://github.com/w3c/mdn-spec-links/ build (tool used for adding MDN annotations to specs), I finally [had to switch that build over to using the https://andreubotella.com/csswg-auto-build/ site instead](https://github.com/w3c/mdn-spec-links/commit/0eb97284b87a17bd753e4c3e48c9457be6089a09). And ever since I made that switch, I’ve not run into a single instance of build breakage happening due to the https://andreubotella.com/csswg-auto-build/ site being unavailable.

> 9. There have already been discussions within the CSSWG to replace this infrastructure. No one has stepped up to do it and no concrete plans have emerged.

Someone did step up to create https://andreubotella.com/csswg-auto-build/, after having developed a concrete plan to make a working alternative for serving up the CSS specs for end users to read.

> So if you want to start yet another discussion to rebuild all this all over from scratch,

I am not suggesting we start a discussion about how to rebuild all the things listed above. I am instead suggesting we have have a discussion about the known highest-priority end-user need we have, and how to optimize for that need.

And meeting that need would not require rebuilding from scratch. Instead, the work has already been done, in https://andreubotella.com/csswg-auto-build/, and the alternative system has already been up and running — with high reliability — for at least 4 or 5 months now.

> Any replacement will also require a commitment from whoever builds it to keep hosting

We don’t require special hosting if we were to use the https://andreubotella.com/csswg-auto-build/ setup. It’s just using the same free GitHub Pages hosting mechanism used by https://w3c.github.io/ — that is, the same hosting mechanism that every other W3C working group has already been using for years to make their specs available.

> it and to maintain it going forward (I also have been maintaining the server infrastructure).

If it’s hosted through https://w3c.github.io/ using GitHub Pages, then we wouldn’t need anybody to give any special maintenance commitment — and it wouldn’t require anybody to maintain separate server infrastructure for it.

> I'm also curious how much effort you think replacing all this will be vs fixing what's already there and who you expect to do the work.

The work on an alternative system has already been done. https://andreubotella.com/csswg-auto-build/ is the existence proof. And it’s already running. I don’t know know much effort was require to create it and make it work — but that doesn’t seem relevant at this point. The work needed (or the bulk of it) has already been done. So I am not expecting anybody to need to do a bunch more work to create it.

As far as estimating how much work is required to fix the existing drafts.csswg.org backend, I’ve got to admit I have absolutely no idea — and I think nobody else in the wider community has any idea at all either. But I’ve seen the assertion that fixing it will require a person-month of engineering effort, and that seems to me like a very surprisingly huge amount of work — and I cannot imagine that switching to deploying a mechanism that uses the https://github.com/andreubotella/csswg-auto-build setup would need anything close to a person-month of engineering effort to make happen.


-- 
GitHub Notification of comment by sideshowbarker
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7500#issuecomment-1185317101 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 15 July 2022 08:39:49 UTC