Using Element as an IRC client

Like many who work in open source communities, IRC is a key part of my daily life. Its simplicity has made it a mainstay. But the lack of richness also makes it unattractive to many newcomers. As a result, newer chat protocols are gaining traction. Matrix is one of those. I first created a Matrix account to participate in the Fedora Social Hour. But since is bridged to Freenode, I thought I’d give Element (a popular Matrix client) a try as an IRC client, too.

I’ve been using Element almost exclusively for the last few months. Here’s what I think of it.


The biggest pro for me is also the most surprising. I like getting IRC notifications on my phone. Despite being bad at it (as you may have read last week), I’m a big fan of putting work aside when I’m done with work. But I’m also an anxious person who constantly worries about what’s going on when I’m not around. It’s not that I think the place will fall apart because I’m not there. I just worry that it happens to be falling apart when I’m not there.

Getting mobile notifications means I can look, see that everything is fine (or at least not on fire enough that I need to jump in and help), and then go back to what I’m doing. But it also means I can engage with conversations if I choose to without having to sit at my computer all day. As someone who has previously had to learn and re-learn not to have work email alert on the phone, I’m surprised at my reaction to having chat notifications on my phone.

Speaking of notifications, I like the ability to set per-room notification settings. I can set different levels of notification for each channel and those settings reflect across all devices. This isn’t unique to Element, but it’s a nice feature nonetheless. In fact, I wish it were even richer. Ideally, I’d like to have my mobile notifications be more restrictive than my desktop notifications. Some channels I want to see notifications for when I’m at my desk, but don’t care enough to see them when I’m away.

I also really like the fact that I can have one fewer app open. Generally, I have Element, Signal, Slack, and Telegram, plus Google Chat all active. Not running a standalone IRC client saves a little bit of system resources and also lets me find the thing that dinged at me a little quicker.


By far the biggest drawback, and the reason I still use Konversation sometimes, is the mishandling of multi-line copy/paste. Element sends it as a single multi-line message, which appears on the IRC side as “bcotton has sent a long message: <url>”. When running an IRC meeting, I often have reason to paste several lines at once. I’d like them to be sent as individual lines so that IRC clients (and particularly our MeetBot implementation), see them.

The Matrix<->IRC bridge is also laggy sometimes. Every so often, something gets stuck and messages don’t go through for up to a few minutes. This is not how instant messaging is supposed to work and is particularly troublesome in meetings.


Generally, using Element for IRC has been a net positive. I’m looking forward to more of the chats I use becoming Matrix-native so I don’t have to worry about the IRC side as much. I’d also like the few chats I have on Facebook Messenger and Slack to move to Matrix. But that’s not a windmill I’m willing to tilt at for now. In the meantime, I’ll keep using Element for most of my IRC need,s, but I’m not quite ready to uninstall Konversation.

Picking communication tools for your community

Communication is key to the success of any project. The tools we use to communicate play a part in how effective our communication is. Recent discussions in Fedora and other projects have made me consider what tool selection looks like. Should Discourse replace mailing lists? Should Telegram replace IRC? I’m not going to answer those questions.

There’s no one right tool, just a set of considerations to think about in selecting communications tooling. Each community needs to arrive at a consensus about what works best for their workflow and culture, and keep in mind that the decision may attract some contributors while driving others away.

In this post, I’m going to broadly lump tools into two categories: synchronous and asynchronous. Many tools can be used for both to a decent approximation, but most will pretty obviously fall into one category or the other. Picking one tool to rule them all is a valid option, but be aware that it immediately favors one category of communication over the other. And keep in mind that for large projects, some sub-teams may choose different platforms. That’s fine so long as people who want to participate know where to look.

Considerations for all tools

Self-hosted or externally-hosted. Do you have the resources to maintain the tool? If you do, that’s a way to save money and maintain control, but it’s also time that your community members can’t spend working on whatever your community is doing. Externally-hosted tooling (either free or paid) might give you less flexibility, but it can also be more isolated from internal infrastructure outages.

Open source or proprietary. This is entirely a value judgement for your community. For some communities, anything that’s not open source is a non-starter. Others might not care at all one way or another. Most will fall somewhere on the spectrum between.

Federated or centralized. Can the community connect their own tools together (e.g. like with email) or is it a centralized system (like most social media platforms)? The trend is definitely toward centralized systems these days, so you may have to work harder to find a federated system that meets your needs.

Public or private. Can outsiders see what you’re saying? For many open source projects, public visibility is important. But even in those communities, some conversations may need to take place in private or semi-private.

Archived or ephemeral. Do you want to be able to go back and see what was said last month, last year, or last decade? Some conversations aren’t worth keeping, but records of important decisions probably are. Does your tool allow you to meet your archival needs?

Considerations for synchronous tools

Sometimes you really need to talk to people in real time.

Mobile experience. It’s 2019. People do a lot on their phones, especially if their contribution to your community happens during their workday or if they travel frequently. What is the mobile experience like for the tools you’re evaluating? It’s not just a matter of if clients exist, but what’s the whole experience. If they disconnect while on an airplane, do they lose all the messages that were sent in their absence?

Status and alerting. What happens if someone stays logged in and goes away for a little bit? Do they have the ability to suppress notifications? Is there any way to let others know “I’m away or busy, don’t expect an immediate reply”?

Audio, video, and screen sharing. Sometimes you need the high-bandwidth modes of communication in order to get your full message across (or just shortcut a lot of back-and-forth). Does the tool you’re looking at provide this? Is it usable for those who can’t participate due to bandwidth or other constraints?

Integrations. Can you display GIFs? The ability to speak entirely in animated images can be either a feature or a bug, depending on the community’s culture. But if it’s important one way or another, you’ll want to make sure your tool matches your needs. Of course, there are other integrations that might matter to. Can your build system post alerts? Does the tool automatically recognize certain links and display them in an particular manner?

Considerations for asynchronous tools

Of course, you’re not all going to be sitting at your computer at the same time. People go on vacation. They live in different time zones. They step away for 10 minutes to get a cup of coffee. Whatever the reason, you’ll need to communicate asynchronously sometimes.

Push or pull. Email is a push mechanism. Your message arrives in my inbox whether I’ve asked it to or not. Web fora are a pull mechanism. I have to go check them (yes, some forum tools provide an email interface). Which works better for your workflow and community? Pull mechanisms are easier to ignore when you want to step away for a little while, but they also mean you might forget to check when you do want to pay attention.

Is it a ticket system? I haven’t really talked about ticket systems/issue trackers because I don’t consider them a general communication tool. But for some projects, all the discussion that needs to happen happens in GitHub issues or another ticket tracker. If that works for you, there’s no point in adding a new tool to the mix.

Please don’t argue with the warning system

“Please don’t argue with the warning system”, Indiana University told a lecturer from its meteorology department as he rightly criticized their communications on Sunday.

Despite being wrong, the university continued to insist that they were making the right choice. Now as a Boilermaker, I’m normally in favor of Indiana University embarrassing itself. But this time, it’s just bad. Warning fatigue can kill people. The false alarm rate is already too high; telling people about warnings that don’t exist only makes it worse.

The “warnings affect the entire county until notified otherwise” statement is only a decade out of date. But I get it, our warning dissemination technology hasn’t caught up with how warnings are issued. You may recall I’ve written a few words on the subject.

The fact that dissemination technology is still (mostly) stuck in a county-based paradigm 10 years after the nationwide implementation of polygon-based warnings is an embarrassment. Emergency management is more than just weather, so I don’t expect emergency managers to know as much as meteorologists. I do expect them to not act silly when they’re corrected by experts. But most of all, I expect things to get better.

I don’t know why I expect things to get better. It’s hard to imagine the large public- and private-sector investments that are necessary to fix the issue. Storm deaths are relatively low, so there’s not even mass tragedy to spur action. It’s much easier to just work around the edges and pretend the glaring issues don’t exist. But if we’re serious about being a Weather-Ready Nation, we need to fix it at some point. Otherwise public institutions will continue making themselves look bad and misinforming the public.

Severe weather outlooks on TV

At the end of October, the Storm Prediction Center changed the categories used in severe weather outlooks in order to more clearly communicate risk. These outlooks, like many NWS products, started as a way of communicating information to other meteorologists, emergency managers, et cetera. Though they weren’t designed with public consumption in mind, social science has helped to shape some of the changes. The Internet means that weather products are available to anyone who is looking for them.

What I’ve noticed since then is that not all of the local TV stations have gone along for the ride. A while ago, I asked one of the local meteorologists about this. His station discussed it internally and decided fewer categories made for less viewer confusion. I don’t have any reason to dispute that.

Severe weather outlook from the Storm Prediction Center.

Severe weather outlook from the Storm Prediction Center.

Severe weather outlook from NBC affiliate WXIN.

Severe weather outlook from NBC affiliate WXIN.

Severe weather outlook from CW affiliate WISH.

Severe weather outlook from CW affiliate WISH.

Severe weather outlook from Fox affiliate WXIN.

Severe weather outlook from Fox affiliate WXIN.

My main concern isn’t that the station doesn’t use the same categories as the SPC, but that different stations in the market use different categories. Of course, they should do what they think is in the best interests of their viewers. I’m certainly not suggesting there be mandatory unification. At the same time, I think stations having different risk categories is more confusing to the public than adding “marginal” and “enhanced” categories. Then again, TV weather seems to be one place that people have a specific and unwavering loyalty. Outside of weather weenies, I’m not sure there are too many people who would even notice differences between stations.

Simplifying winter weather products

Decades after the National Weather Service began issuing watches and warnings, many members of the public don’t know what the difference is. When you throw in different products, the confusion only mounts. Too often, the products are based on meteorological distinctions that don’t necessarily mean much to the public. Take, for example, a nor’easter that struck New England in December. Or the confusion around the landfall of Sandy, which became extratropical shortly before landfall.

Some products you might see in a winter event include blizzard, winter storm, high wind, wind chill, ice storm, lake effect snow, and freezing rain. Plus flood products and special weather statements. How should the public try to understand these differences?

In general, I’m a proponent of getting the important information to the consumer as quickly as possible with minimal effort required. This case is an exception. Trying to cram the important information into the headline leads to public confusion and forces forecasters to spend time trying to decide which of a handful of products are correct instead of focusing on communicating impact.

I’m in favor of a smaller set of products, with specific impacts delineated in the text. A “winter storm” and “blizzard” product with watch, warning, and advisory (maybe) levels would go along way toward making the products more clear to the public. Everyone could spend less time thinking about the differences between the products and more time focusing on the impacts and preparedness.

If you’re interested in the official specification for the current suite of winter products, see

NWS products are not ready for public consumption

Decades ago, dissemination of National Weather Service products was largely done via third parties, particularly broadcast media. Then along came the Internet and suddenly NWS products became readily available to the public at-large. This should have been a benefit, but the products have not adjusted to this new paradigm.

Forget that text products are still in all-caps (I’ve found that I have a harder time reading discussions that are in mixed case). Severe weather warnings give information out of order. Warnings and even regular forecasts suffer from discontinuity at forecast area boundaries. Worst of all, forecasts do not convey uncertainty, instead providing a single number instead of a possible range.

The snow storm that hit (to one degree or another) the east coast this weekend is an excellent example of how forecast uncertainty was not well-communicated. In some areas, the forecast was quite accurate. In others, snowfall predictions were far too high. The forecasters knew there was a high degree of uncertainty about the forecast, so why did the public and civic leaders?

It’s hard to fault individual forecasters. They work hard within the system to produce valuable forecasts for the American people. It’s the management and technology that prevent the message from getting out. In recent years, the industry (including the private sector) has begun to understand the need for social science to accompany meteorological science. Hopefully this new focus will help to make products for the modern public.

Disseminating storm-based warnings

Earlier this month, I wrote about the format and wording of severe weather warnings, and how to effectively shape those warnings. In those previous posts, we came to the conclusion that county sections are pretty lousy ways to define warnings. Defining warnings based on counties leads to over-warning, and using county subsections are ambiguous to the public. Storm-based polygon warnings are the most accurate way to define warnings, but they come with their own problems. First, as I previously discussed, there’s the issue of having to shape around county boundaries. Secondly, they present some challenges in dissemination.

Storm-based warnings are easily transmitted visually (though they still require a basic level of geographical knowledge that I’m not sure we can assume), so they work well on TV, Internet images, and smartphone apps. They are really poor in text or audio formats. Warnings disseminated through audio or text must still reference vaguely-defined county regions. As a result, storm-based warnings lose some of their benefit immediately.

NOAA All-Hazards Radio’s Specific Area Message Encoding (SAME), which is used to selectively activate weather radio receivers, works on a county basis. As a result, the NWS obsoleted its own technology when it switched to storm-based warnings in 2007. On the other hand, county-based warning distribution like SAME has one distinct advantage: the ability to pre-warn. A common recommendation when programming weather radios is to have the radio activate for warnings for your own county and also the surrounding counties. This allows additional lead time in some events. The current warning paradigm does not allow for such a setup.

The future of warning dissemination will be hitting people in the pocket. Mobile phones are the best way to reach a large (and growing) portion of the population. The Wireless Emergency Alert system is a good start. WEA will automatically send warnings to cell phones in affected areas (this also helps to address the issue of people driving, especially through areas they wouldn’t normally be), but it has some room for improvement. The character limit of WEA messages is 90, which is just over half the length of a traditional text message, resulting in a very information-sparse alert. In addition, it will be based on the tower‘s location, not the phone’s. This means that people will receive warnings that do not include them (or worse, will not receive warnings that do include them). Of course, it also requires that people have a WEA-capable device.

In the end, a multi-layered approach is required. Broadcast media must continue to remain a valuable partner. WEA and third-party smartphone apps should continue to get warnings to people’s phones. Weather radio technology should either be upgraded to support location-based alerting or be gracefully retired. Warning siren systems should be upgraded so that they can be sounded selectively (most systems still sound county-wide), or better yet scrapped entirely.

Effectively shaping warnings

Earlier this week, I wrote about the format and wording of severe weather warnings in order to most effectively communicate the necessary information to the public. In that post (and the excellent discussion that took place in the comments), I referred several times to the problems that can arise from the shape of warnings. Before I let loose on that, let’s set some historical context. From 1953-2005, the National Weather Service issued warnings on a by-county basis. This lead to over-warning unaffected areas.

In 2005, the NWS began a pilot program to issue warnings with a forecaster-defined polygon shape. In this way, the warnings could be issued such that they reflect actual threats and not political boundaries. All forecast offices began using these “storm-based warnings” in 2007, but the system still isn’t perfect.

Radar image showing two separate polygon warnings side-by-side

Sample polygon warning from WFO Indianapolis. Source:

Even though forecasters can issue warnings that are based on the atmosphere, they still must consider the political boundaries. Many warning dissemination systems (more on this in a future post) don’t support polygon warnings, so if a warning would normally clip a corner of a county, the forecaster must consider whether or not to cut a notch out of the warning. (I asked for clarification from a friend who is an NWS forecaster. He said there’s a setting that optionally excludes tiny slivers of counties. “We try to do our best to serve two masters between county based communication systems and scientifically based warnings. The main focus at all times, however, is getting information to people who are threatened as fast as possible and in as useful a manner as possible.”)

The problem is further compounded when a storm exists along the boundary between the County Warning Areas (CWAs) of two forecast offices. Current NWS practice does not allow a warning to extend outside an office’s CWA. Since CWAs edges are determined by the county borders, they are frequently uneven. A storm may clip a small portion of another office’s CWA, and the issuing forecaster must shape the polygon to avoid that portion. In order to include said portion, the other office must issue its own warning. While offices will often coordinate when storms are near a CWA boundary, I seriously doubt that any forecasters will take the time to make sure their polygons match precisely. The resulting discontinuity can be confusing to the public and makes absolutely no sense from a threat perspective. The storm does not respect political boundaries.

Radar image with severe thunderstorm warning polygons. The shape of the middle polygon is influenced by the boundary between county warning areas

A recent severe weather event in central Indiana. The warning in the middle of the image was issued by the NWS office in Northern Indiana. The southern extent of the warning is defined by the boundary between the Northern Indiana and Indianapolis county warning areas.

Removing the county-border issues from the polygon system still doesn’t lead to perfection. Polygons themselves suffer from some issues. Notably, they’re ripe for being over-large in order to improve verification scores, as Patrick Marsh posted earlier this week. The other key concern is that, as I mentioned above, some warning systems have no concept of polygons. NOAA All-Hazards Radio (also known as “weather radio”) is a prime example., as are outdoor warning sirens (some locations have the ability to sound sirens selectively, but it is by no means ubiquitous). Until these systems are modernized, even the best polygons will still lead to over-warning.

Effectively communicating to the public

One of the main challenges a meteorologist faces (and this is true for many professions. I eagerly await a post from Matt Simmons drawing a parallel in systems administration) is effectively getting a message to the public. This becomes especially important in times of severe weather when the timeliness and clarity of the message can literally be the difference between life and death. While the National Weather Service and the media do a good job, there’s a lot of room for improvement. Let’s consider the three questions a person needs answered:

  1. Am I threatened?
  2. If so, what do I do about it?
  3. When am I in the clear?

Now compare this to an actual warning.

WUUS53 KIND 011733

133 PM EDT SUN JUL 1 2012

This is just header information. The public rarely encounters it directly.



Okay, so let’s assume I know what county I’m in. Am I in the right part of the county?


The first question to be definitively answered is the third one.


There’s some town names here and a description of the threat. Maybe I can figure out if I’m threatened by this or not.



Oh, okay! My city isn’t listed, so I’m probably in the clear. Folks in Delphi know that they are threatened. The first question is answered.




And here, basically at the end of the warning, is the answer to question 2.

LAT…LON 4073 8652 4070 8652 4069 8637 4063 8636
4034 8641 4045 8693 4057 8689 4057 8678
4066 8678 4067 8676 4073 8676 4074 8675
4074 8663
TIME…MOT…LOC 1733Z 280DEG 19KT 4052 8679

The latitude/longitude pairs define the shape of the warning (more on that in a bit). This can be used to provide really good answers to question 1.

Your typical severe weather warning answers all three of the questions we base our discussion on, but in the wrong order. Arguably, question 1 gets answered first, although it relies greatly on the geographical awareness of the public. I suspect many adults are aware of what county they live in (due to school districts, libraries, property taxes, etc), but if they work in a different county, do they know that county’s name? Can they name the surrounding counties (this is useful for preparedness. If the county to your west is under a warning, chances are good you might be soon)? The fact that subsections of counties (e.g. “northeastern Tippecanoe County”) are variable and undefined only add to the confusion.

The fact that the “call to action statement” (what NWS meteorologists call the answer to question 3) comes at the tail end of the warning means that a full minute may pass until it’s made clear what actions someone should take. In many cases, the lead time is sufficient that this additional time is acceptable, but in short-lead-time situations (for example, the Joplin, MO tornado of 2011) every second counts.

It’s not bad to give people more information than they need, especially when it reinforces your point. One example comes from a derecho that hit Louisville, KY on July 13, 2004. This storm caused widespread damage through southern Indiana and central Kentucky. In order to make it clear that this was an exceptionally dangerous storm, one of the forecasters at the NWS office in Louisville made mention of “hurricane force winds” in the warnings. Although this wasn’t strictly necessary, it helped to make the danger more clear in the mind of the public. Extra information can be valuable, but it should never get in the way of the main point.

So how would I re-format warnings?



<counties>, including <cities>

<call to action, don’t die, etc.>

<THIS WARNING EXPIRES AT <expiration time>

<More explanation, supporting info>

The media has an advantage here, as they can format their presentation of the warning however they’d like. The NWS is stuck with a defined format. It’s worth noting that decades ago, the public did not receive NWS products directly; they were filtered through the broadcast media first. In modern times, All-Hazards Radio, weather websites, and mobile apps are putting more NWS products directly in front of the public. So far, the NWS has not updated warning text to fit this new model.

One thing you may have noticed is that my version doesn’t mention the office issuing the warning. I had this discussion with a recent meteorology graduate last week. What use is knowing what office issued the warning? Most people probably don’t know what NWS office serves them. Furthermore, a warning may be issued by a backup office if the primary office is unavailable (e.g. if the office staff is taking shelter because they’re about to get hit by a tornado). Adding the issuing office does nothing to answer or reinforce the three questions. It’s not extra information, it’s extraneous.

Note: I was going to add some comments about the shape of warnings, but this post is long enough and that rant won’t be short. Look for it in the next few days.