Looking into Semaphore a bit it seems it is broader than just showing messages in Gerrit. It's an API to show such information across a broad range of relevant front ends. I can imagine that the same thing would be useful in Chrome (getting these messages in tools beyond Gerrit). 

Android is using a Gerrit UI plugin to show the messages in Gerrit. Assuming we had the relevant infrastructure in place, we could look into re-using Androids plugin, though the behavior is simple enough that it might make more sense to incorporate into our existing plugins like chromium-behavior. 

Added jparent@ and seanmccullough@ to put this idea on their radar. I think it's an interesting one. But would need to be prioritized as a project with staffing.

I've long wanted this.  If there is a relatively cheap way (say 2 SWE days?) to add this to just Gerrit that would be high value to our users, and is worth an investment on our end.  Ideally we'd have something we can share across our apps, but that would likely be a more substantial effort, certainly worth considering though.

A quick work estimate would be helpful here.

If we did it with a hard-coded message that required a Gerrit plugin deployment it would be pretty quick and easy. Still likely more than 2 days since someone on the team would need to learn Gerrit development. But that feels just a little too limiting to me.

I think a better minimal scope would be a deployed app engine (or other place) app that has a simple API to set and get message and a plugin that polls for it. I know nothing about how hard it is to setup a simple app engine app. I can ask some folks and get a better work estimate in the new year. 

Chatted with Sean a bit about this. Depending on the sensitivity of these messages and how much we need to worry about the permissions of setting message & viewing them there are some low effort ways we could implement this.

We could do something like check the message to be displayed into git and then let a Gerrit plugin just make a request to Gitiles to fetch the message. Permissioning for write could be handled by existing OWNERS & committer permissions for the repo (infra?). But the easiest thing to do would be to put this in a world readable location so we don't need credentials for the fetch. Given the open source nature of Chrome this might be ok? Might need to look into Gerrit usage for Chromium and make sure that this wouldn't be an issue for Gitiles / GoB at whatever rate of polling we'd do.

> Given the open source nature of Chrome this might be ok?

Definitely agree. The announcements would be equivalent to what we currently put in PSAs to public mailing lists. If we need to convey any private info, I imagine we'd post it in an RVG bug and link the bug in the announcement (that's what we do today, seems to work OK).

> We could do something like check the message to be displayed into git

SGTM, especially since everyone (or at least everyone that's on call) should know how to update files in git. And FWIW, I think it'd be prudent to keep the update process as streamlined as possible in the interest of getting the message out their sooner (eg: limited CL review, preferably no CQ requirements).
 
And thanks for looking into this, Andy!