drupal.org error 500 page twitter widget is unusable

Thank you for opening this @podarok - a Mastodon replacement is a good idea, I think. Or a proper status page service.

Status page service not that easy, because of a dedicated maintenance needed
Mastodon on other hand - just a twitter like feed anyone or drupal_infra team can push messages to without additional effort or human onboarding

I suppose an account could be opened on https://drupal.community and some tool like https://gitlab.com/idotj/mastodon-embed-feed-timeline could be leveraged to replace the embed on 500 error pages.

We’re trying a few ways to read the feeds.

There are some discussions and tests being made here: https://drupal.slack.com/archives/C1BMUQ9U6/p1688665965950989

Once there is a consensus i can update here too.

Option 1: Using aggregator module and exposing the blocks: https://fjgarlin-drupal.dev.devdrupal.org/security
Option 2: Using https://github.com/andy-blum/fed-embed with minimal styling (max-height and overflow): https://fjgarlin-drupal.dev.devdrupal.org/about/core

We know that option 1 would need some additional coding to expose aggregator blocks into panels UI, and probably additional styling; and 2 would only need a little bit of styling, but wouldn’t leverage the server-side caching of aggregator.

For the 5xx error page, option 2 would be the only one available (unless we use another solution like the one suggested in #6).

Option 3 - iframe of profile at mastodon

https://www.drupal.org/about/core → now has the Twitter embed replaced with a feed from Mastodon that updates hourly with Drupal’s aggregator module. This avoids any privacy/performance/etc considerations for loading 3rd-party JS.

That of course won’t work for Drupal.org’s 500 error message. I think it would be best to replace it with the right tool for the job, a link to a status page.

I investigated using our existing monitoring & alerting tools, DataDog & Opsgenie, since they have some incident management built in. Neither looked like a clear improvement for our use case; and their integrations with public status page services look like they could be clunky in mapping fields across. We might end up having to log into another service, which is not what we want to do when troubleshooting an incident.

The best fit looks like incident management on GitLab.com. (Not on git.drupalcode.org so we can update the status page when it is offline.) We can make templates for different incidents, create & update incidents, and a pipeline publishes a static page to S3.

Looks great, @drumm

What if we just embed mastodon page without introducing rss or aggregators?
There are services which help now ( e.g. alias https://mstdn.social/@drupal_infra@bird.makeup ) and iframe should work perfectly for https://drupal.community