Fedora Hubs and Meetbot: A Recursive Tale

Fedora Hubs

Hubs and Chat Integration Basics

One of the planned features of Fedora Hubs that I am most excited about is chat integration with Fedora development chat rooms. As a mentor and onboarder of designers and other creatives into the Fedora project, I’ve witnessed IRC causing a lot of unnecessary pain and delay in the onboarding experience. The idea we have for Hubs is to integrate Fedora’s IRC channels into the Hubs web UI, requiring no IRC client installation and configuration on the part of users in order to be able to participate. The model is meant to be something like this:
Diagram showing individual hubs mapping to individual IRC channels / privmsgs.
By default, any given hub won’t have an IRC chat window. And whether or not a chat window appears on the hub is configurable by the hub admin (they can choose to not display the chat widget.) However, the hub admin may map their hub to a specific channel – whatever is appropriate for their team / project / self – and the chat widget on their hub will give visitors the possibility to interact with that team via chat, right in the web interface. Early mockups depict this feature looking something like this, for inclusion on a team or project hub (a PM window for user hubs):
mockup showing an irc widget for #fedora-design on the design team hub
Note this follows our general principle of enabling new contributors while not uprooting our existing ones. We followed this with HyperKitty – if you prefer to interact with mailing lists on the web, you can, but if you’ve got your own email-based workflow and client that you don’t want to change at all, HyperKitty doesn’t affect you. Same principle here: if you’ve got an IRC client you like, no change for you. This is just an additional interface by which new folks can interact with you in the same places you already are.
Implementation is planned to be based on waartaa, for which the lead Hubs developer Sayan Chowdhury is also an upstream developer.
Long-term, we (along with waartaa upstream) have been thinking about matrix as a better chat protocol that waartaa could support or be ported to in the future. (I personally have migrated from HexChat to Riot.im – popular matrix web + smartphone client – as my only client to connect to Freenode. The experiment has gone quite well. I access my usual freenode channels using Riot.im’s IRC bridges.) So when we think about implementing chat, we also keep in mind the protocol underneath may change at some point.
That’s a high-level explanation of how we’re thinking about integrating chat into Hubs.

Next Level: HALP!!1

As of late, Aurélien Bompard has been investigating the “Help/Halp” feature of feature hubs. (https://pagure.io/fedora-hubs/issue/98)
The general idea is to have a widget that aggregates all help requests (created using the meetbot #help command while meeting minutes are being recorded) across all teams / meetings and have a single place to sort through them. Folks (particularly new contributors) looking for things they can help out with can refer to it as a nice, timely bucket of tasks that are needed with clear suggestions for how to get started. (Timely, because new contributors want to help with tasks that are needed now and not waste their time on requests that are stale and are no longer needed or already fixed. On the other side, the widget helps bring some attention to the requests people in need of help are making, hopefully increasing the chances they’ll get the help they are looking for.
The mechanism for generating the list of help requests is to gather #help requests from meeting minutes and display them from most recent to least recent. The chances you’ll find a task that is actually needed now are high. As the requests age, they scroll further and further back into the backlog until they are no longer displayed (the idea being, if enough time has passed, the help is likely no longer needed or has already been provided.) The contact point for would-be helpers is easy – the person who ran the #help command in the meeting is listed as a contact for you to sync up with to get started.)
The mockups are available in the ticket, but are shown below as well for purposes of illustration:

Main help widget, showing active help requests across various Fedora teams
Main help widget, showing active help requests across various Fedora teams

Mockup showing UI panel where someone can volunteer to help someone with a request.
Mockup showing UI panel where someone can volunteer to help someone with a request.

An issue that came up has to do with the mapping we talked about earlier. Many Fedora team meetings occur in #fedora-meeting-*; e.g., #fedora-meeting, #fedora-meeting-1, etc. Occasionally, Fedora meetings occur in a team channel (e.g., #fedora-design) that may not map up with the team’s ‘namespace’ in other applications (e.g., our mailing list is design-team. Our pagure.io repo is ‘/design’.) Based on how Fedora teams use IRC and how meetbot works, we cannot rely on the channel name to get the correct namespace / hub name for a team making a request during a meeting using the meetbot #help command.
Meetbot does also have a mechanism to set a topic for a meeting, and many teams use this to identify the team meeting – in fact, it’s required to start a meeting now – but depending on who is running the meeting, this freeform field can vary. (For instance – the design team has meetings marked fedora_design, fedora-design, designteam, design-team, design, etc. etc.) So the topic field in the fedmsg meetbot puts out may also not be reliable for pointing to a hub / team.
One idea we talked about in our meeting a couple of weeks ago as well as last week’s meeting was having some kind of lookup table to map a team to all of its various namespaces in different applications. The problem with this is that because meetbot issues the fedmsgs used to generate the halp widget list of requests as soon as the #help command is issued – it is meetbot itself that would need to lookup the mapping so that it had the correct team name issued in its fedmsg. We couldn’t write some kind of script or something to reconcile things after the meeting concluded. Meetbot itself needs to be changed for this to work – for the #help requests put out on fedmsg by meetbot to have the correct team names associated with them.

Which Upstream is Less Decomposed?

Do you see dead upstreams? Zombie image
Zombie artwork credit: Zombies Silhouette by GDJ on OpenClipArt.

We determined we needed to make a change to meetbot. meetbot is a plugin to an IRC bot called supybot. Fedora infrastructure doesn’t actually use supybot to run meetbot, though. (There haven’t been any commits to supybot for about 2 years.) Instead, we use a fork called limnoria that is Python 3-based and has various enhancements applied to it.
How about meetbot? Well, meetbot hasn’t been touched by its upstream since 2009 (7 years ago.) I believe Fedora carries some local patches to it. In talking with Kevin Fenzi, we discovered there is a newer fork of meetbot maintained by the upstream OpenStack team. That hadn’t seen activity in 3 years, according to github.
Aurélien contacted the upstream OpenStack folks and discovered that, pending a modification to implement file-based configs to enable deployment using tools like Ansible, they were looking to port their supybot plugins (including meetbot) to errbot and migrate to that. So we had a choice – we could implement what we needed on top of their newer meetbot as is and they would be willing to work with us, or we could join their team in migrating to errbot, participate in the meetbot porting process, and use errbot going forward. Errbot appears to have a very active upstream with many plugins available already.

How Far Down the Spiral Do We Go?

Credit: Lost in the Woods by johnny_automatic on OpenClipArt.
Credit: Lost in the Woods by johnny_automatic on OpenClipArt.

To unravel ourselves a bit from the spiral of recursion here… remember, we’re trying to implement a simple Help widget for Fedora Hubs. As we’ve discovered, the technology upon which the features we need to interact with to make the feature happen are a bit zombiefied. What to do?
We agreed that the overall mission of Fedora Hubs as a project is to make collaboration in Fedora more efficient and easy for everyone. In this situation specifically, we decided that migrating to errbot and upgrading a ported meetbot to allow for mapping team namespaces to meeting minutes would be the right way to go. It’s definitely not the easy way, but we think it’s the right way.
It’s our hope in general that as we work our way through implementing Hubs as a unified interface for collaboration in Fedora, we expose deficiencies present in the underlying apps and are able to identify and correct them as we go. This hopefully will result in a better experience for everyone using those apps, whether or not they are Hubs users.

Want to Help?

we need your help!
Does this sound interesting? Want to help us make it happen? Here’s what you can do:

  • Come say hi on the hubs-devel mailing list, introduce yourself, read up on our past meeting minutes.
  • Join us during our weekly meetings on Tuesdays at 15:00 UTC in #fedora-hubs on irc.freenode.net.
  • Reach out to Aurélien and coordinate with him if you’d like to help with the meetbot porting effort to errbot. You may want to check out those codebases as well.
  • Reach out to Sayan if you’d like to help with the implementation of waartaa to provide IRC support in Fedora Hubs!
  • Hit me up if you’ve got ideas or would like to help out with any of the UX involved!

Ideas, feedback, questions, etc. provided in a respectful manner are welcome in the comments.

14 Comments

  1. […] Fedora Hubs and Meetbot: A Recursive Tale […]

  2. […] Fedora Hubs and Meetbot: A Recursive Tale […]

  3. […] for its chat feature. I talked quite a bit about the basics of how we think this could work (see “Fedora Hubs and Meetbot: A Recursive Tale” for all of the […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.