If you're seeing this linked because you used an internal-to-RH proprietary realtime chat system,
please consider instead interacting on an asynchronous, public channel such as a GitHub issue,
Bugzilla (but uncheck the "Private bug" bits), or public mailing list like fedora-devel@
or centos-devel. Another good alternative is https://discussion.fedoraproject.org/
You'll see it said that Red Hat is an enterprise software company with a FOSS development model. Now, for a variety of reasons we use (multiple) internal proprietary real-time chat systems. This is understandable; not everything can be public for example.
But that said, it's way too easy to over-use real-time chat when an asynchronous conversation would work instead.
Further, since Our Code is open our development processes should be too.
If you have an important issue that should get attention, a good combination is to file an upstream issue (or BZ, email, etc.), then send a link to it via internal chat with any extra business-related prioritization (e.g. "Customer X is hitting this").
Some issues demand real-time collaboration. But, at least try to summarize after what was discussed in the relevant issue/bugs.
A related thing is this blog post on Rust governance and the "No new rationale" rule. If there's a long asynchronous debate happening, sometimes it can make sense to convert the async discussion to real-time. But, avoid making any final decision there that wasn't at least an option in the original asynchronous discussion.