- From: Michael[tm] Smith via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Jul 2022 02:08:26 +0000
- To: public-css-archive@w3.org
sideshowbarker has just created a new issue for https://github.com/w3c/csswg-drafts: == Replace the https://drafts.csswg.org/ backend == ### Summary This is in part a specific concrete proposal to consider replacing the current https://drafts.csswg.org/ backend with the backend from https://andreubotella.com/csswg-auto-build/ — but more broadly, it’s a detailed problem description, with a suggestion that we use this issue to discuss what our actual user requirements are for the site, and how we could best address those user needs. ### Problem description The record of “https://drafts.csswg.org/ down again” reports from users in https://github.com/w3c/csswg-drafts/issues/6528 shows that for nearly a year or more, users have run into chronic problems with not being able to read specs from the https://drafts.csswg.org/ site because its backend has become wedged. As far as how often that backend gets wedged and prevents users from being able to read the specs there, the comment at https://github.com/w3c/csswg-drafts/issues/6528#issuecomment-1157497732 has the following image that seems to indicate it happens at least 3 or 4 days out of every week.  The responses so far in https://github.com/w3c/csswg-drafts/issues/6528#issuecomment-1184750613 and https://github.com/w3c/csswg-drafts/issues/6528#issuecomment-1158540588 have stated that unless someone can provide funding for a person-month of engineering effort, the site is not going to ever get fixed. It seems worth noting that: * If a person-month of engineering effort is required to fix the current backend, then we have a responsibility to consider whether that backend that requires that much work to fix is the right choice to begin with * If only one person understands the current backend and has access to fix the current problems with it, we have a responsibility to consider whether a backend which has a single point of failure like that is the right choice to begin with. * If the backend setup isn’t documented anywhere, and it’s not using a software stack that we have a lot of other contributors in our space who’d likely be able to help maintain it, we have a responsibility to consider whether a backend which is that relatively idiosyncratic is the right choice to begin with. So it seems necessary to consider alternative solutions that: * don’t require a person-month of engineering effort to make happen * won’t leave us all continuing to rely on a single person to keep the site up and running reliably * could be maintained by a much larger number of people * are based on a software stack that’s already widely used and widely understood by contributors in our space ### One proposed solution Replace the current https://drafts.csswg.org/ backend with the backend from https://andreubotella.com/csswg-auto-build/ #### Pros * Very high reliability/availability. * Uses the same GitHub Pages backend that all other W3C working groups are already using at https://w3c.github.io/ URLs. * Based on a software stack that’s already widely used and widely understood by contributors in our space. * Won’t require a person-month of engineering effort to make happen (instead, is already working and available). * Won’t leave us all continuing to rely on a single person to keep up and running — giant pool of other people who could help. #### Cons The only downside I am aware of is that GitHub Pages has some limitations the current https://drafts.csswg.org/ doesn’t have — most notably an inability to do server-side redirects and an inability to set arbitrary HTTP response headers. However, those limitations in GitHub Pages are well-known and well-understood, and there are workarounds or mitigations. Lack of server-side redirects is probably the most-serious limitation — but it can be addressed by using client-side redirects instead. Admittedly not optimal, but does work — as evidenced by the fact https://andreubotella.com/csswg-auto-build/ is already using it. But from a user point of view, the effect’s the same — users still end up in the right place. So, given the problems we have with the current https://drafts.csswg.org/ setup — and the cost required to fix it — the benefits make the limited replacement worth the tradeoff. As far as the inability to set arbitrary HTTP response headers, it’s actually already possible to address that too — by using a Service Worker. See, for example, https://github.com/gzuidhof/coi-serviceworker. If anybody’s tempted to dismiss this proposal (of switching to the https://andreubotella.com/csswg-auto-build/ setup) out-of-hand, please resist that temptation and please let’s instead try to use this issue as place to have a constructive discussion about what our user requirements are and what the right solution would look like. https://andreubotella.com/csswg-auto-build/ may turn not to meet our requirements — but at least seriously considering it and having a specific discussion about it can help lead us to figuring out a solution that meets the user needs. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7500 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 02:08:28 UTC