generally landing in the same place as @danschick-wmde, i.e. reliable links without manual intervention, either programatically or to a latest-stable branch. my preference would be to a latest stable tho as then we could share this link in more places knowing it will continue to be reliable (ex. in an email, on wikiba.se, in telegram headers, etc). that said I'm fine with a manual solution for the interim while we lay the foundation for the above. ideally we'd get there before too long tho. let's discuss the implementation details if there's some nuance there.

we realized that " Front-end... static display of analyzed data / key metrics" (currently assumed to live in google sheets) requires a remote server to bring data into sheets via an easily accessible api. so we are removing this spec from our scope. it will be revisited in a follow-on project.

I didn't know where to put this exactly because im not quite sure how you'll build this but I found myself wondering at the difference between times when we're basically syncing the raw data (ex. number of properties in an instance) vs syncing the result of some logic (ex. the connectivity score) vs some sort of aggregated stat (total findable triples in ecosystem). certainly we'll want to be able to 'send' all three types from the sheet to the db.

@RickiJay-WMDE I found this reddit thread to be a useful way in https://www.reddit.com/r/googlesheets/comments/mvs2vo/performance_limitations_of_google_sheets/ :)

@RickiJay-WMDE jfyi considering our desire to use sheets as our main dashboard for the MVP, I reviewed some of the data points in the db and updated the list of data to get into the sheet. see main notes on ticket.

after evaluating google sheet's viability (and flexibility while we're still figuring this all out) it was determined that google sheets would be a better fit for the current MVP scope. so grafana is not going to be used during the mvp.