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 Matrix.org 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.

Pros

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.

Cons

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.

Overall

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.

Setting boundaries when working in communities

Kat Cosgrove recently had a tweet that hit home:

I haven’t taken any meaningful time off of work in the last 14 months because it feels kinda pointless. I’m just going to be sitting at home thinking about work so I might as well be doing work. Invariably, what I fear is happening while I’m not at work is much worse than what is actually happening. Yay, anxiety!

But also, there’s some guilt when you’re paid to work in a community where a lot of people are volunteering. I don’t feel like I can say “hey, it’s after my work hours” because many in my community only participate outside of their work hours. Add to that the global nature of open source communities and that means that there’s always something to devote my time to.

I think it would be easier to come in as an outsider who is just doing the job for a paycheck. But working in a community where you previously volunteered makes the urge to be around all the time so much stronger. It can be really hard to set boundaries because it feels like you’re devaluing the donated time of others.

It’s a blessing and a curse. I happen to think I’m pretty good at my job (and the fact that I’m anything other than a failure should tell you something) and I know that’s because it’s more than a paycheck to me. But that’s also what makes it so hard to draw boundaries.

My manager (who is very good at reminding me to take care of myself) recently compared it to working for a startup. Everyone pitches in wherever they can, even when it’s not on the job description. That’s incredibly true in open source projects, except there’s no exit. It’s not like you’re working hard now so you’ll get a stupid-large pile of cash when a big company acquires you or you have an IPO. If the project is successful it…keeps being a startup forever.

For now, I’m holding up pretty well. I’m balancing working too much with non-work interests (even if a lot of them look like work to the outside observer). But I wonder how long that can hold. And I wonder how others in a similar position make it work over the long term.

Other writing: April 2021

What have I been writing when I haven’t been writing here?

Stuff I wrote

Fedora

Stuff I curated

Fedora

FOSS licenses permit, not restrict

Last week, Matthew Wilson shared a very correct take on Twitter:

A few people in the mentions argued that the GPL is doing it wrong by his definition. This is incorrect. Copyleft licenses do not prevent the user from doing things, they ensure that subsequent users can do the same thing.

This may seem like a semantic argument, but there’s substance to it. All licenses (except those that amount to a public domain dedication) contain some conditions, minimal though they may be. It’s important to remember that the default is that you can do nothing with a work. Copyright is by definition a monopoly on a work.The entire point of free and open source software licenses is to tell you what you can do, because the default position is that you can’t.

One of the most annoying things about license wars is the argument that one category of license is somehow more free than another. That’s dumb. Both copyleft and permissive licenses promote freedom, just from different perspectives. Permissive licenses give the next person in line the freedom to do (essentially) whatever they want. Copyleft licenses preserve freedoms for all subsequent users, no matter how many hands the work passes through. There are plenty of philosophical and practical reasons you might choose one class of license over the other (I tend to prefer copyleft licenses, myself), but it’s wrong to paint one or the other as anti-freedom.

Getting back to Matthew’s point, there has been a fair amount of license weaponization in the last few years. By this I mean the use of a license to try to exclude a certain class of user. Some of this I’m sympathetic to (e.g. the “ethical source” movement), some of this I’m not (e.g. the various “you can do what you want, just don’t make a successful software-as-a-service offering” licenses that have popped up). In both cases, I think copyright is the wrong mechanism for achieving the goals.

Excluding classes of users is antithetical to ideals free software and open source. That may be okay. As I’ve written, free software is not the end goal. But if you’re going to claim to be open source, you should act open source.

On CLAs, DCOs, and pinky swears

Recently, Van Lindberg decided to kick over a hornets’ nest on Twitter:

I don’t think either of them particularly change the risk profile to the end user of a project. Both a contributor license agreement (CLA) and developer certificate of origin (DCO) depend on the contributor asserting something that is correct. In my experience, the most common issue is a developer submitting code they can’t. This could be because they’re reusing code under an incompatible (including proprietary) license.

Another possibility is that they are not the copyright owner. This can be the case when contributing as part of a job or while using their employer’s resources. Van suggests that a CLA helps prevent this because it passes through the contributor’s employer’s legal department. That strikes me as naÏve. Most contributors, I suspect, will sign the CLA on their own without consulting anyone else.

Fundamentally, CLAs and DCOs depend on contributors understanding enough about intellectual property to ensure their contributions are valid. Neither mechanism is particularly effective at that.

This doesn’t mean they’re useless. My 2018 Opensource.com article gives more information on that.

Cursed house: The Monkees

This is the first post in a series of personal stories about how my parents’ house has some really bad luck.

I’ve been a fan of The Monkees for nearly as long as I can remember. Davy Jones signed the liner notes for my copy of their greatest hits CD. I not only have watched “Head”, but I own it, and I like it. As a kid, I recall frequently asking my mom if a song on the radio was by The Monkees. Almost every time it turned out to be the Beatles, but that’s neither here nor there.

My lifelong fandom is undoubtedly due to the hours I spent watching the TV show in a hotel room when I was three years old. You see, my family lived in a hotel while we rebuilt our house.

It wasn’t a planned rebuild, mind you. The project was thrust upon us when the house caught fire.

I’m not entirely clear on the details, but somehow the fire happened when the house was in limbo. My parents were stuck with it, but the previous owner got the insurance payment? I don’t know; I was three. At any rate, it turns out that the previous owner had similar circumstances befall them at least one other time. Not suspicious at allllll.

But if the house is cursed, my parents were lucky in one regard: they had the carpets cleaned that night. The dampness slowed the fire long enough for the volunteer fire department to arrive. This kept the house from being a total loss.

It also gave me one hell of a headache. I ran through the house, being a three year old, and immediately fell when my wet shoes hit the vinyl floor in the kitchen. I still remember sitting on the back porch crying. My grandpa was there with us and he let me come spend the night to help me feel better.

I have a vague recollection of my parents showing up at his house later that night or the next morning. I assume they talked about the fire. I don’t remember if I had any reaction to the news or not. Ah, to be young again!

But this post is about The Monkees. So there we are, living in a hotel. My parents, my infant sister, and me. There’s not a lot for a kid to do in a hotel, especially when dad is at work (or working on making the house livable again) and mom is caring for a baby. So I spent what was probably a good deal of time watching TV.

This was around the time that The Monkees were having a resurgence in popularity, and so the show was on TV. I don’t remember specifics, but I know I liked the show. While the jokes went faaarrr over my head, the silliness is evident even to a three year old.

The Monkees got me through what was probably an incredibly stressful winter for my parents. I’ve been a fan ever since.

Balancing incoming tasks in volunteer projects

Open source (and other volunteer-driven) communities are often made up of a “team of equals.” Each member of the group is equally empowered to act on incoming tasks. But balancing the load is not easy. One of two things happens: everyone is busy with other work and assumes someone else will handle it, or a small number of people immediately jump on every task that comes in. Both of these present challenges for the long-term health of the team.

Bystander effect

The first situation is known as the “bystander effect.” Because every member of the team bears an equal responsibility, each member of the team assumes that someone else will take an incoming task. The sociological research is apparently mixed, but I’ve observed this enough to know that it’s at least possible in some teams. You’ve likely heard the saying “if everyone is responsible then no one is.”

The Bystander effect has two outcomes. The first is that the team drops the task. No one acts on it. If the task happens to be an introduction from a new member or the submission of content, this demoralizes the newcomer. If the team drops enough tasks, the new tasks stop coming.

The other possibility is that someone eventually notices that no one else is taking the task, so they take it. In my experience, it’s generally the same person who does this every time. Eventually, they begin to resent the other members of the team. They may burn out and leave.

Oxygen theft

Sometimes one or two team members jump on new tasks before anyone else does. Like the delayed version in the bystander effect scenario, this can lead to burn out. But worse, it can drive away team members who want to take tasks. If they’re constantly missing work because they weren’t able to immediately jump on it, they’ll go find other places to contribute. I call this “oxygen theft” because it’s like sucking all of the oxygen out of the room: it puts out the flames.

I have been an oxygen thief myself. Shortly after I started as the Fedora Program Manager, I became an editor on the Fedora Community Blog. I was publishing regular posts and I happen to be a decent editor, so it made sense to give me that privilege. But because Fedora was my day job, I was often the first to notice new submissions. Over time, I eventually became the only editor working on posts. By accident, the editorial team became a team of one. That’s on my list to fix in the near future.

Solving the problem

Letting either the bystander effect or oxygen theft cases go for too long harms the team. But with volunteers, it’s hard to balance the work. Team members may not have consistent availability. For example, if one of the team members dayjob schedule varies from week. They probably don’t have evenly distributed availability, either. Someone who is paid to be on a project will likely have a lot more time available than someone volunteering.

One way to solve the problem is to take turns being in charge of the incoming tasks for a period of time. This addresses “if everyone is responsible then no one is” by making a single person responsible. But by making it a rotating duty, you can spread the load.

After learning my lesson with the Fedora Community Blog, I was hesitant to be too aggressive with taking tasks as an editor of the Fedora Magazine. But the Magazine team was definitely suffering from the bystander effect.

To fix this, I proposed having an Editor of the Week. Each week, one person volunteers to be responsible for making sure new article pitches got timely responses and the comments were moderated. Any of the editors are free to help with those tasks, but the Editor of the Week is the one accountable for them.

It’s not a perfect system. The Editor of the Week role is taken on a volunteer basis, so some editors serve more frequently than others. Still, it seems to work well for us overall. Pitches get feedback more quickly than in the past, and we’re not putting all of the work on one person’s plate.

[If you are intrigued by this half-baked post, you’ll enjoy my book on program management for open source projects, coming from The Pragmatic Bookshelf in 2022.]

Distinguishing between tasks and projects

I was talking to a colleague recently about leading a volunteer group at work. One of the issues she mentioned was that the group sometimes has a hard time separating tasks and projects. If you look around, you’ll find plenty of blog posts (mostly from software companies trying to sell you their tool). Many of them share a similar adherence to the Project Management Institute’s definition of a project. While that can be useful, it’s more formal than necessary.

In my mind, the distinguishing factor is the number of states.Tasks have two states: “not done” and “done”.Projects have multiple states.

For example, I treat doing the dishes as a task. There’s not really an in-between state. Okay, there could be. Scrubbing, rinsing, and drying could all be distinct states. In practice, a dish moves between the three so quickly that it’s of no benefit to track the state. Doing the dishes is a single act in terms of my time. I’m not going to start and then pause midway through (barring my kids doing something that requires immediate attention).

Laundry, on the other hand, I treat as a project. It has distinct states of sorting, washing, drying, and folding. Unlike the dishes example, they don’t happen all at once. I’ll load the washer and then I have to wait until I can put the clothes in the dryer.

To use work examples, writing an email is a task. Yes, there’s a state of “writing” and I may not compose it all at once, but it’s essentially a single thing. Writing a release announcement is a project. First I write it, then it gets reviewed, then it gets scheduled.

This brings up another point about the states. Tasks change state in one direction, but projects can move between states. Once they’re done, they’re done. After I send an email, it’s done. New tasks may come as a follow-up, but those are new tasks. The release announcement may go back and forth between “writing” and “review” several times before it’s done.

The astute reader will notice that the states sound a lot like tasks. You can look at the laundry project as a collection of four tasks: sort the laundry, load the washing machine, load the dryer, fold the laundry. That’s a valid approach. For me, it makes more sense to think about it in states instead of a collection of steps.

Part of this is probably due to the tools I use. For tasks, I use a todo list application (Todoist, specifically) to track and plan. For projects, I use a Kanban board (Trello, generally, but Taiga for a few things. And Todoist’s new board feature for my laundry. More on all of this in a future post). For particularly complex projects, I’ll add sub-projects or tasks to track them more granularly.

Sidebar: why PMI’s definition is too formal

The Project Management Institute defines a project as “It’s a temporary endeavor undertaken to create a unique product, service or result.” While this is not unreasonable in the context of my conversation, the page goes on to add a lot of extra baggage. In common usage, a project is something that takes multiple steps to accomplish. The structure, process, and documentation of a Project™ are entirely unnecessary for how most people use the word.

File a bug, but where?

It’s easy to tell someone to file a bug. Knowing where to file it isn’t quite as simple. In a large project like Fedora, there is no One Tracker to Rule Them All.

Red Hat Bugzilla comes the closest. That’s where most software bugs should be filed. Except for Fedora CoreOS which would rather you use their GitHub tracker. And a few other components, which would very much prefer issues be filed upstream.

But for non-software issues, Bugzilla may or may not be the place. Components still exist for documentation and websites, although those are mostly handled via Pagure repos now. (I should really remove those components.) And some teams discuss software features in their Pagure repo for collaboration and then might open a Bugzilla bug if other tools need one.

Of course, knowing which platform is only the start. You also have to know which component (in Bugzilla) or repo (in Pagure) is right. This isn’t always clear when you’re familiar with the inner workings of the project and is entirely opaque to outsiders. A casual user is not going to know (or care) which URLs happen to be owned by the websites team versus the docs team versus who knows what other team.

And that, dear reader, is one of the key features of a centralized tracker like Bugzilla: mis-filed bugs can be trivially passed to the right team. With independent repos, you force users to know your project’s org chart

Of course, Bugzilla can be pretty heavy and is generally more complicated than you need. There’s no right answer. There’s just how you’re willing to balance the tradeoffs.

In general, I think putting software issues (bugs, features, etc) in Bugzilla and process issues in a team’s Pagure repo is the right approach. But ultimately, teams decide for themselves how they will work.

[If you are intrigued by this half-baked post, you’ll enjoy my book on program management for open source projects, coming from The Pragmatic Bookshelf in 2022.]

Book review: A Place to Start

Jim Grey is a pretty ordinary guy. So why bother reading stories of his life? Because he tells them so well.

I first came to know of Jim through his roads website. At some point, I started reading his blog “Down the Road“. I can’t recall how long it’s been now, but it’s probably the better part of a decade, if not from the beginning in 2007. Although we’ve never met, I’ve come to feel like I know him. Not just because we share similar interests and have mutual friends, but because the way he is able to write his personal stories in a way that welcome strangers in.

Jim does not share every detail; his writing respects the privacy of those in his life. Nonetheless, he is able to warmly and openly share his stories in a way that invites to sit down and listen. There is no false modesty, no exaggeration, and no self-importance. Just honest tales of his life shared because he wants to share them.

Down the Road started in 2007 as a way to process and recover from a rough time in his life. Jim’s new (okay, six months old at this point) book A Place to Start collects some of the posts from the first two years of the blog.

The book is split into three parts: stories, essays, and faith. The stories are personal tales from all eras of Jim’s life. Told in no discernible order, they’re more like a conversation than a timeline. The short essays section contains reflections on lessons Jim has learned over the years. The faith section contains a mix of his personal experiences with his Christian faith along with what I would call sermons.

Admittedly, the faith section was the least engaging part for me. Being religiously indifferent myself, I suppose I’m not inclined toward that kind of story. Nonetheless, I do enjoy the way he is able to discuss his faith in a way that does not feel like evangelism. He shares his beliefs and how they color his life; the reader is free to do with that what they will.

Since each chapter is a blog post, they’re all short. This makes A Place to Start a great book for when you can only read in quick bursts. Even if you’ve never heard of Jim Grey before, this book with worth a read.

A Place to Start is available in print and digital forms from Midnight Star Press. I received no compensation for this review.