StatusPage

[MattIPv4]

This PR adds all the customisations used on the new status page to the repo as a backup. These should be updated whenever changes get made to the status page itself.

[richardlau]

@nodejs/build Do we think this is the right place for this (as opposed to a separate repository)? My fear is it will end up like the benchmarking website scripts and coverage scripts which live here in build but are essentially not being actively maintained. Committing these here would also have the barrier of anyone wanting to maintain them (@MattIPv4, for example) having to join the Build WG in order to get write permissions to merge in changes.

[MattIPv4]

I posted about this in the build IRC/Slack and the initial suggestion was that here might be easier vs having to create a new repo. I feel these files likely will see very little change going forward, as the design will probably remain rather static. So, with that in mind, I'm not too worried about access, I can just make a PR if it ever needs to be changed.

Equally though, I wouldn't object to having a dedicated repo for it (like cdnjs/statuspage) so that I (and others) could just push changes up whenever.

[richardlau]

My concerns aren't blocking... while I'd prefer they were kept separate if the other members of the team are happy for these files to live in this repository that's fine by me.

[AshCripps]

Thought I agree it will just get forgotten about in build, will there actually be that many changes to warrant a seperate repo?

[MattIPv4]

I don't think there will be a crazy number of changes, as I said above I hope it'll pretty much just stay as it is. I imagine there will be some refinements though, both to improve accessibility etc. as well as to ensure the design is kept in-line with what's happening on nodejs.dev.

[sam-github]

I don't mind them being here rather in yet-another-repo, but there should be a doc/ file that describes where the data came from, so that they can get re-backed up/confirmed to reflect the current state. Also useful would be info on how to use the backups, if restore from backup is necessary. If its super obvious, just a link to the relevant status admin page is likely enough.

Also, the status page is still in the experimenting-with-it phase, but just as a heads up, its not going to get used without docs on how and when to use it, so eventually that policy needs to be added, too.

I don't know if access control has been considered yet, but ideally membership in a GH team would be sufficient to get access, and that team would be another build infra team, in the build-wg README (synced with ncu-team sync).

And while I'm thinking of the TBD list... also needed would be changes to nodejs/nodejs.org to point to the status page.

Maybe this PR should be WIP and commits for the other necessaries can be added until its ready to go live, then we merge?

[sam-github]

As for @richardlau 's pref for another repo, I can see how that keeps it in its own place, unentangled with anything in the build repo. But then, its so small, maybe that isn't worth the admin overhead (it would need a contributing.md, a governance, worse case, maybe even chartering as a wg so that there is a membership policy). Having it here makes that a bit simpler. Also, the motivation for it was that build (I think?) would be expected to update it under certain conditions, so the policies might be here. I think its 6 of one vs a half-dozen of the other where it should be, but note, once the content is in this PR, or even merged, moving it out is pretty easy if we decide that makes things easier.

[MattIPv4]

I don't mind them being here rather in yet-another-repo, but there should be a doc/ file that describes where the data came from, so that they can get re-backed up/confirmed to reflect the current state. Also useful would be info on how to use the backups, if restore from backup is necessary. If its super obvious, just a link to the relevant status admin page is likely enough.

Makes sense, will write this in a bit. It's pretty simple: there is an admin page for colors, then another for custom css/html.

Also, the status page is still in the experimenting-with-it phase, but just as a heads up, its not going to get used without docs on how and when to use it, so eventually that policy needs to be added, too.

Will appreciate some help with that once we get to that stage. :)

I don't know if access control has been considered yet, but ideally membership in a GH team would be sufficient to get access, and that team would be another build infra team, in the build-wg README (synced with ncu-team sync).

There is discussion in #2265 about access. Imo, as many people as possible assuming they know what they're doing.

And while I'm thinking of the TBD list... also needed would be changes to nodejs/nodejs.org to point to the status page.

Would you like me to raise a draft PR over there now to add the status embed and links in relevant places?

Maybe this PR should be WIP and commits for the other necessaries can be added until its ready to go live, then we merge?

Sure, I think it makes sense to make this the status page PR :)

[mhdawson]

Is there a reason this is not going to be a repo under the node.js org?

[MattIPv4]

Hm?

[mhdawson]

My question is if there is a reason that the twitter account is run by you personally versus being something managed by the project with you being one of the people who can post to it.

[mhdawson]

But I guess that is covered below.

[MattIPv4]

Yeah, I made it at the same time as setting up the status page itself. Going forward, no one should actually need to ever post manually to it, as status page automation will do that, so handing it over to ops@jsf makes sense once we're ready to go.

[mhdawson]

We should have the account be under the auspices of the project/OpenJS Foundation. Is that the plan?

[MattIPv4]

Yeah, once we've figured out access, I think it makes sense to make ops@jsf the owner of twitter & statuspage.

[mhdawson]

Also, the status page is still in the experimenting-with-it phase, but just as a heads up, its not going to get used without docs on how and when to use it, so eventually that policy needs to be added, too.

I'll echo this, that before we say this is "live" we need a clearly defined process for how outages are added/resolved, what expectations are on who will do what etc.

Ideally I think what would work best is if it was based on an issue in the node.js repo (for greatest visibility) and then being approved by two approvals from Node.js collaborators. We trust our collaborators to push code so it quite likely makes sense to trust them with decide what is a reportable incident and when it is resolved. Even better if after the approvals simply adding a tag (which any collaborator can do) would result in the incident being pushed to the status page. If this could not be automated, it could be done manually to start.

[MattIPv4]

Ideally I think what would work best is if it was based on an issue in the node.js repo (for greatest visibility) and then being approved by two approvals from Node.js collaborators.

I briefly mentioned this in #2265, but essentially that'd need someone to write a custom solution to integrate with their API. Not something I'm familiar with really.

I would personally recommend having a policy in place and then a set of individuals with access to the StatusPage control panel, as the UI there is probably much easier to use than writing a issue based solution to emulate all of that.