Greg Sutcliffe

In August 2021, the Ansible community voted to accept Matrix as an official chat platform (alongside and equal to IRC). This marked a major evolution in the communication of the project, and opened the door to more ways for us to connect with each other. It also followed a substantial amount of planning from the community team, in terms of architecture we had in mind. In this talk, we'll take a look back over our original architecture & proposal, how the rollout has gone, and where we think we're going next.

There's much we could cover in this talk, but we'll definitely have content on the 2-homesever architecture we used (and why), on how adoption is going with our community (bridges will feature here, at least) and community building & promotion (expect armchair-sociology while I talk about rich interaction mediums, but also things like newsrooms, interaction fragmentation, etc). I'll also be attempting to gather some feedback from our community to present as well.

Who is this talk for: We hope it'll be of interest to anyone thinking of recommending Matrix for their community - whether a FOSS community, or more generally, there's things to think about first and arguments that can be re-used. There will also be interest for existing Matrix users too, in terms of lessons learned and wishlist features for the future.

Remarkably, the Matrix community still does not seem to have a equivalent to things like the venerable mIRCstats or PISG packages (which generate data based on a local IRC log). In this lightning talk, I'll present a new package I'm working on to present similar data for Matrix rooms. We'll have a quick demo and lots of pretty graphs to look at.

ChatStat aims initially to replicate the same kind of HTML report that these older packages created, and we'll show how to use it on your own host to generate stats for your rooms using the Matrix API.

Since Matrix has bridges, we can also directly gather data on these from connected rooms (e.g. the screenshot shows the split between Matrix and IRC users over a 2 week period) and we will show how to accomplish this too.

Lastly we'll talk about the underlying data structure and how to use it to build new graphs that ChatStat does not yet do itself.

Who is this talk for: Anyone who runs one or more Matrix rooms and wishes to generate visualisations of them. Or anyone who likes pretty graphs :)

How do we decide when a discussion is complete? How do we know we've heard from enough people, or that the topic isn't dead yet? Deciding how to take decisions in a community is hard - in this talk, I'd like to ways to handle it.

Figuring out when to close a discussion is really hard - and more so if all the participants are only using forums/mailinglists/chat rather than being face-to-face. Knowing that you've heard from the right people, trying to ensure quiet voices are heard, and making sure you're not cutting the discussion too early (or too late) really matters. In this "talk" I'd like to bring some examples of such discussions from our community (e.g. things which caused conflict, things which caused communications blocks, and so on), talk about how we handled them, and discuss ways in which we could improve - hopefully to the benefit of everyone present.

Viewing the potential changes when changing the environment on a Puppet agent is challenging - much can be altered, and often the only way to know what will change is to actually run it. Using octocatalog-diff (from GitHub) and TheForeman (using a new plugin) we can now view these changes up front, in the UI, before switching the agent to the new env.

Please note that this talk was originally scheduled to be given at 11:00 The talk originally in this slot, "Next Generation Config Mgmt" by James Shubin will now take place at 11:00.

Octocatalog-diff is a commandline tool to show the differences between two puppet environments for a specific node before the node is moved to the new env. That's great, but not everyone wants to work on the commandline

In this talk we'll look at a new Foreman plugin (foreman-puppetdiff) which brings this functionality to the Foreman UI. We'll cover the basics of octocatalog-diff (installation, uses, limitations) and then show how to set up the Foreman plugin and use it in the UI.

A look at how Foreman uses automation internally to handle testing and release management.

In this talk I'll walk through how the Foreman developers use automation to run end-to-end tests, automatically test Pull Requests (including building packages with submitted changes in) and manage the release process for a new release of Foreman. I'll also cover how we use Foreman to manage the Jenkins slaves, and briefly talk about what we'd still like to accomplish with our automation.

The Foreman's new Metal-as-a-service feature

The Foreman is adding a Metal-as-a-Service feature in the near future. In this lightning talk, we'll show the current status of the work, and discuss where it's heading to eventually.

The Foreman is a complete lifecycle management tool for physical and virtual servers. Adding Metal-as-a-Service functionality will extend the ways in which The Foreman can help manage hardware within a given workflow.