Publish meeting agenda online

[Mark-Simulacrum]

Currently lang and compiler agendas are generated by running the tooling locally, but that can mean a recompile and is generally heavier weight than just visiting a webpage. It should be pretty easy to move the entry points into the triagebot library (rather than lang-agenda...) and then serve them from the existing HTTP server.

Since they run a number of pretty rate limited GH queries, it's probably a good idea to cache the produced markdown within triagebot for ~5-10 minutes or so. That shouldn't be too hard to do; likely hand rolling it is easiest.

[apiraino]

Some thoughts about the possible implications (please validate my assumptions because I'm not 100% sure):

• moving the agenda generation online wouldn't allow me to test locally little tweaks that I might want to submit as future patches (ex. #1593). Being able to run the tool both locally and online wouldn't remove this capability.

• Today, anyone generating T-lang and T-compiler agenda use their own GH token to run queries so there's a vague user access control. With a completely online version I assume everyone would use the same token (set server-side)? We would lose this granularity.

• How would that solve the rate-limiting issue? If I'm hitting the GH API too often then someone else would be impacted, too.

• (related to the above point) Caching, in this context, would also be a tiny step backwards in my workflow because it wouldn't allow generating an agenda immediately after operating on other things online (say, updating issue/PR labels). A flag to choose whether to use the cache or not wouldn't remove this capability.

[Mark-Simulacrum]

We could still support running it locally, either via existing method directly or by running the site. I don't expect the story there to get significantly worse.

For the configuration use case, I expect we could expose that if desired (as a query param). It would mean more complicated caching, but not too much.

I'm not sure I understand the user access control angle - this is all querying public data, right? I'm not seeing why per user tokens help us much. I could easily be missing something though!

I would expect that if you're working on the agenda actively (e.g., modifying labels) you probably still want to run a local copy. I think it's possible we could have the caching later directly on the GitHub queries (using if-not-modified or whatever the right hradee is), which would ease concerns around rate limiting, but I suspect the workflow you have would continue to be best served with a local run. (I will note that we have the long term ability to migrate triagebot to be a GitHub app, which will increase our rate limit roughly 3x I think, and depending on whether we want to, for this particular interface we could do the full oauth flow to make each user have their own rate limit pool. This is a lot of work though.)

In general I think the lang workflow here is much simpler than yours, so my hope is we can meet that need and then move forward from there.

[apiraino]

agree on your comments :+1: I'll just clarify this point I didn't explain too well:

I'm not sure I understand the user access control angle - this is all querying public data, right? I'm not seeing why per user tokens help us much

by "user access control" I just meant that using a single shared server-side token would also share responsabilities. A user being rate limited (for any reason, not necessarily a bad actor) would block everyone using that token.

[Mark-Simulacrum]

This is done for lang agendas; those are currently rate limited to 1 request every 30 seconds, which is enough to prevent problems on the github side. I don't think this causes any difficulty for regular usage of the endpoint, though we don't have metrics in place to validate that assumption (probably good to add them).

For now, I think this is basically done; we can extend it with compiler agendas and other things at a later point if desired pretty easily.

[apiraino]

Cool! w.r.t. the rate limiting issue incurring in the T-compiler agenda I have a log of all the REST traffic performed. I'd like to investigate if moving some of them to the github GraphQL endpoint would help reducing the number of calls.