Category Archives: Project Management

Balancing incoming tasks in volunteer projects

Posted on by
1

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

Posted on by
1

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?

Posted on by
Reply

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.]

Projects shouldn’t write their own tools

Posted on by
Reply

Over the weekend, the PHP project learned that its git server had been compromised. Attackers inserted malicious code into the repo. This is very bad. As a result, the project moved development to GitHub.

It’s easy to say that open source projects should run their own infrastructure. It’s harder to do that successfully. The challenges compound when you add in writing the infrastructure applications.

I understand the appeal. It’s zero-price (to write; you still need the hardware to run it). Bespoke software meets your needs exactly. And it can be a fun diversion from the main thing you’re working on: who doesn’t like going to chase a shiny for a little bit?

Of course, there’s always the matter of “the thing you wanted didn’t exist when you started the project.” PHP’s first release predates the launch of GitHub by 13 years. It’s 10 years older than git, even.

Of course, this means that at some point PHP moved from some other version control system to Git. That also means they could have moved from their homegrown platform to GitHub. I understand why they’d want to avoid the pain of making that switch, but sometimes it’s worthwhile.

Writing secure and reliable infrastructure is hard. For most projects, the effort and risk of writing their own tooling isn’t worth the benefit. If the core mission of your project isn’t the production of infrastructure applications, don’t write it.

Sidebar: Self-hosting

The question of whether or not to write your infrastructure applications is different from the question of whether or not to self-host. While the former has a pretty easy answer of “no”, the latter is mixed. Self-hosting still costs time and resources, but it allows for customization and integration that might be difficult with software-as-a-service. It also avoids being at the whims of a third party who may or may not share your project’s values. But in general, projects should do the minimum that they can reasonably justify. Sometimes that means running your own instances of an infrastructure application. Very rarely does it mean writing a bespoke infrastructure application.

Applying the Potter Stewart rule to release blockers

Posted on by
1

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description, and perhaps I could never succeed in intelligibly doing so. But I know it when I see it.

Justice Potter Stewart in Jacobellis v. Ohio

Potter Stewart was talking bout hard-core pornography when he wrote “I know it when I see it”, but the principle also applies to release blockers. These are bugs that are so bad that you can’t release your software until they are fixed.Most bugs do not fall into this category. It would be nice to fix them, of course, but they’re not world-stopping.

Making a predictable process

For the most part, you want your release blockers to be defined by specific criteria. It’s even better if automated testing can use the criteria, but that’s not always possible. The point is that you want the process to be predictable.

A predictable blocker process provides value and clarity throughout the process. Developers know what the rules are so they can take care to fix (or avoid!) potential blockers early. Testers know what tests to prioritize. Users know that, while the software might do something annoying, it won’t turn the hard drive into a pile of melted metal, for example. And everyone knows that the release won’t be delayed indefinitely.

Having a predictable blocker process means not only developing the criteria, but sticking to the criteria. If a bug doesn’t violate a criterion, you can’t call it a blocker. Of course, it’s impossible to come up with every possible reason why you might want to block a release, so sometimes you have to add a new criterion.

Breaking the predictable process

This came up in last week’s Go/No-Go meeting for Fedora Linux 34 Beta. We were considering a bug that caused a delay of up to two minutes before gnome-initial-setup started. I argued that this should be a blocker because of the negative reputational impact, despite the fact that it does not break any specific release criterion. I didn’t want first time users (or worse: reviewers) to turn away from Fedora Linux because of this bug.

QA wizard Adam Williamson argued against calling it a blocker without developing a specific criterion it violates. To do otherwise, he said, makes a mockery of the process. I understand his position, but I disagree. While there are a variety of reasons to have release blockers, I see the preservation of reputation as the most important. In other words, the point of the process is to prevent the release of software so bad that it drives away current and potential users.

Admittedly, that is an entirely subjective opinion. I expect disagreement on it. But if you accept my premise and acknowledge that you can’t pre-write criteria to catch every possible, then it follows that squishy “I know it when I see it” rules are sometimes okay.

Can’t you just make that a criterion?

The best blocking criteria are objective. This aids automated testing and (mostly) avoids arguments about interpretation. But that’s not always possible. Even saying “feature X works” is open to argument over what constitutes “working”.

The challenge lies in how to incorporate “this bug is bad even though there’s no specific rule” without making the process unpredictable. In this case, Adam’s position makes a lot of sense. It’s much easier to write rules to address specific issues and apply them retroactively. Of course, doing that in a go/no-go meeting is perhaps straining the word “predictable” a bit, too.

So what happened?

In the case of this specific bug, we had an escape hatch. The release was likely to be declared no-go for other reasons, so we didn’t need to come to a decision either way. With a candidate fix available, we could just pull that in as a freeze exception and write a new criterion for the next time.

Because of this, I decided not to push my argument. I declined to propose a criterion in-meeting because I wanted to take some time to think about what the right approach is. I also wanted to spend some time thinking about the blocker process holistically. This gives me a blog post to publish (hi!) and some content for a project I’ll be announcing in the near future. In the meantime, I’ve proposed a change to the criteria.

Working from home: my advice

Posted on by
2

There are as many articles about working from home as there are people who work from home. But I’ve been asked by a few people about my experiences, so looking back on the last nearly seven years, here’s what stands out.

Let’s keep a few things in mind first. Not everyone has the privilege of being able to work from home. In the midst of a pandemic, I feel for them. Also, working from home for a few weeks as an emergency is different from doing it all the time. Routine work from home you plan ahead for. It probably doesn’t involve having your partner and children around all the time while you also worry about a global pandemic and economic collapse. Just do the best you can and understand that your best now probably looks a lot different than your best a few months ago.

Your environment

Ideally, you’ll want a separate room that’s walled off from the rest of the house. This gives you the ability to focus and sets boundaries for you and others. If that’s not possible, get yourself the most secluded space you can. Make sure you have enough space for your laptop and any additional equipment you might need. Make sure there are power outlets available. I also ensure there’s space for mug of coffee or a cup of water, depending on the time of day.

When it comes to noise, you might not get much choice. If you like having chaos in the background, that’s great. With a partner, pets, or kids at home, you’ll probably get that. Noise canceling headphones are a good thing to have, but keep in mind that “noise canceling” means “the hum of your HVAC” not “the shriek of your toddler”. I personally tend to listen to podcasts. I’m generally not paying active attention, but the background talking helps. If I’m reading intently or writing, then I’ll shut it off.

Also consider what’s behind you. You’ll probably be on video calls a lot. Does the background send the message you want? Most people will understand a messy room, but if it bothers you, now’s the time to address it. Be particularly careful if someone can walk into frame unexpectedly. Years ago, I’m pretty sure I saw someone walk out of the shower in the background of a call with a coworker. That was awkward. You may consider having some kind of visual indicator: a flag or a light or something. Anything that will make it clear to those around you that you’re “on air” can help them avoid being in the meeting unexpectedly. But also consider that everyone else is going through this and a cute animal or kid can help everyone relax for a minute.

If you can help it, don’t work from a bed or couch. They’re too comfortable and I’ve found it’s really hard to maintain focus. The only time I’ve worked from bed is when I’ve felt particularly unwell but couldn’t bring myself to not work. (That is a personal failing, not an admirable trait.)

Try to find somewhere with sunlight, too. Especially in winter, having some sunshine really helps my mood. Consider where it will come in, though. You probably don’t want it directly in your face as you look at the screen, nor directly over your shoulder.

Your communication

Get ready to embrace your employer’s video platform of choice. I work in an open source community where a lot of daily communication happens through text-based chat. But video calls add an important human dimension. The in-person conversations you used to have? They happen on a webcam now!

If you have multiple monitors, put the thing you’re looking at on the one with the webcam. That might be the chat application, but it also could be a shared document that you’re looking at. But I can say from experience that it’s really disorienting to be looking at someone in profile the whole time.

On a similar note, try to find a good angle for your webcam. It’s best if it can catch you straight on. Up-nose shots are no fun and looking-down-on-your-forehead shots seem weird.

If your bandwidth isn’t up a video call, disable the video. It’s better to have the audio than nothing. If you’re not normally working from home, you might not have paid for the bandwidth you need, especially if others in the house are streaming movies or something. Also keep in mind that some providers throttle the upload bandwidth, which means that you might be receiving the call clearly, but your video or audio might be on the strugglebus. A business-class connection will generally not have that limitation, so it may be worth checking with your provider on that.

One thing you won’t get working remotely is the random water cooler chatter. That can be really helpful for team bonding. In previous jobs, I’ve done things like pair people up with randomly-selected coworkers and say “schedule a 15 minute call in the next two weeks to talk about anything you want.” I have a script that will draw names out of the hat for you. If you have a chat tool like Slack, IRC, etc, have a channel devoted to chit-chat. People can pop in and shoot the breeze without worrying about bothering someone who is in the zone.

Your self

Dress for success. Or at least for work. In cold weather, I put on jeans. In the summer, I wear shorts. What I don’t wear is pajama pants. I’ve found that I just can’t motivate myself to get work done on days I stay in my pajama pants. Not everyone has that problem, so if you find it works for you, great!

You might also want to shower. Or not. I won’t say how often I shower, but I can assure you it’s not daily. A lot depends on how I feel. If I feel like I need a shower, I take one. Sometimes that’s in the morning, but it’s usually at night or occasionally midday. You may find that you need to do your whole morning routine in order to feel motivated for work. That’s fine, but don’t expect that everyone else will.

Try to get some exercise if you can. I’m really bad at this myself, especially when I’m busy or the weather is bad. But when the weather is nice, a 20 minute walk around the neighborhood is a good chance to get away and think for a few minutes. A standing desk or treadmill desk can help too, or even some hand weights that you use during a call.

You know what’s great? Naps! It’s hard to do this at an office, but one of the things I really like about working from home is that I can go lie down for 20 minutes. “But, Ben!” you say “isn’t that like stealing from the company?!” I look at it this way: I could spend 20 minutes taking a nap, or two hours sitting at my desk but just sort of mindlessly staring at my screen. Which one seems better?

At some point, you’ll want to eat. I see a lot of advice that says “don’t eat at your desk”, but I do that almost every day. I did that when I worked in an office, too. For me, it was a way to shorten the work day a bit. For you, do what works best for you. Experiment a little bit. For me, I also know that I should not keep food within arms reach because I will eat it. All of it. Having a little bit of physical separation from food goes a long way.

Perhaps the most important thing is to give yourself some slack. Being a human is hard, and being a human in the time of pandemic is harder. You have a lot on your mind, and it’s okay if you’re not always at your best. Especially if you’re working from home in a suboptimal situation.

Your boundaries

You should have them. Working from home can really blur the line between work and home. It’s okay to step away for a few minutes to load laundry or run the vacuum. It’s not okay to keep working until 11pm because suddenly your living room is now your office. This is where having a separate office space helps. If you can make it happen.

Communication boundaries with coworkers are important, too. Don’t send an IM if it could be an email or a message in a broader channel. In a previous job we set up an escalation process for help requests in Slack:

  1. Ask in a product- or customer-specific channel with no tagging names, @here, or @channel
  2. If sufficient (use your judgment, based on the urgency) time goes by and you haven’t gotten an answer, repeat the message with @here to alert folks who are available
  3. If that still doesn’t get a response, send an IM to the person you think could help

Your routine

Like I said above, some people find they need to go through the whole routine in order to get motivated for work. That might mean doing makeup and hair and getting dressed in your “grown up” clothes. I’ve even heard of some people who drive their car around the block once just to have that mental routine of a morning commute.

I, on the other hand, do none of that. The closest thing to routine I have is making coffee before I sit down at my desk. For me, I love that I can be out of bed and at work five minutes later. I am not at all a morning person. What I do miss is having a commute home. Especially if you have kids, it can be hard to go straight from work stress to kid stress with no break in between. I don’t really miss the act of commuting, just the time to switch gears. For me, I found that was a good time to do 10 minutes of meditation. It helped me calm down after work and it gave me just enough of a break to be less frazzled with the kids.

Your distractions

I love working from home, but it’s not all great. Being able to step away for 5 minutes to get house work done is a great mental relief. But it’s also possible to get carried away, especially if you’re trying to avoid a hard problem at work. Unloading the dishwasher is fine. But don’t let it snowball into then cleaning out the fridge and scrubbing the stove top and and and.

If you have roommates, spouses, children, etc, they need to know when you’re working and that you should be left alone except in emergency. Find a way to signal that, like wearing your headphones when you walk through the house.

You can do this

Whether you’re making work-from-home a permanent thing, or you’re just work-from-home-during-a-pandemic-oh-god-what-is-happening-in-this-world, I hope some of the advice here helps. If you only take away 12 words, let them be: set boundaries, do what works for you, and go easy on yourself.

Book review: People Powered

Posted on by
Reply

Jono Bacon knows something about communities. He wrote the book on it, in fact. And now he has written another book. People Powered is a guide for how companies can create and curate communities.

I often see companies try to start what they call “communities”. In reality, they are ways for the company to get free labor that provide no real benefit to the the participants. But it doesn’t have to be that way. A community that doesn’t benefit the sponsoring company is not likely to continue receiving sponsorship. But if there’s no benefit to the community members, the community will not thrive. Only when everyone involved gets value from the community will the community be vibrant.

A community mission is different than your business vision, but tightly wound around it.

All too often, books like this prescribe the One True Way™. Bacon does not do that. He fills the book with many things the reader should do, but he also makes it clear that there are many right ways to run a community, just as there are many wrong ways.

People Powered is a starting point, not an answer. As I was reading it, I thought “this is a good set of recipes”. Further on, Bacon used the same metaphor. Curse you, Jono! But it’s an apt metaphor. The book presents advice and knowledge based on Bacon’s 20 years of community management. But each community has specific needs, so the reader is encouraged to selectively apply the most relevant parts. And in the tradition of open source, plans should be iterative and evolve to meet the changing needs of communities. Like any good cook, the recipe provides a starting point; the cook makes adjustments to taste.

If I could sum up People Powered in two words, I would pick “be intentional.” Given two more words, I’d add “be selective.” People are often tempted to do all the things, to be all things to all people. And while that may be in the future of a community, getting started requires a more specific focus on what will (and more importantly, what won’t) be done.

People Powered is full of practical advice (including a lot of calls-to-action to find resources on jonobacon.com). But it also contains more philosophical views. Bacon is not a psychologist, but he has made a study of psychology and sociology over the years. This informs the theoretical explanations behind his practical steps. It also guides the conceptual models for communities that he lays out over the course of the book. And to prove that it’s a Jono Bacon book, it includes a few references to behavioral economics and several to Iron Maiden.

I really enjoyed this book. Some of it was obvious to me, given my community leadership experience (admittedly, I’m not the target audience), but I still got a lot of value from it. Chapter 9 (Cyberspace and Meatspace: Better Together) particularly spoke to me in light of some conversations I’ve had at work recently. People Powered is an excellent book for anyone who is currently leading or planning to lead a community as part of a corporate effort.

People Powered (affiliate link) is published by HarperCollins Leadership and was released yesterday.

Disclosures: 1. I received a pre-release digital review copy of People Powered. I received no other consideration for this post (unless you purchased it from the affiliate link above). 2. Jono Bacon is a personal friend, but I would tell him if his book was awful.

Using the wrong tool for the job

Posted on by
1

My first professional job was as a systems administrator in a small academic department on a large university campus. One of the worst parts of this job was dealing with the poster printer the department made available to students and faculty. It was self-service the whole way — users were expected to design and print their own poster. They could come to us for help when the printer malfunctioned (as it often did), but that was about it.

One of the results of this was that people, particularly the graduate students, did their poster design in PowerPoint. It was ubiquitous, it was familiar, and it produced something that looked poster-like. It also didn’t play nicely with the printer. PowerPoint was designed to make slide presentations, not 42″ wide posters. It’s not that PowerPoint posters didn’t work, it’s that they didn’t work quite right. The margins were a little off. Sometimes elements wouldn’t be quite where you expected them. It annoyed the hell out of me.

The wrong tool is easier

But as I’ve gained some experience, I’ve come to understand why people use the wrong tool for the job. It’s because the tool isn’t as wrong as it seems. Why should a graduate student spend time learning a design tool that they’ll use once per year when they can get a good enough result from what they already know?

Spreadsheets are the most widely-used database in the world (I’m guessing) because they’re ubiquitous and easy to start with. By the time you’ve outgrown what’s reasonable in a spreadsheet, you’re already committed. It’s why my post on date-based conditional formatting in Google Sheets is one of this blog’s most-read posts, even though it’s a poor fit for a spreadsheet.

People’s jobs are bigger than a particular task that they try to accomplish with a piece of software. Tools that require an up-front investment — even if that pays of over a short amount of time — are going to be a non-starter. This short-term thinking is natural. It’s not a user problem, it’s a management problem.

The wrong tool isn’t wrong

There’s also the case where what seems like the wrong tool is a failure to properly identify the problem. Take this tweet:

Using an excavator to row a raft down a river seems wrong. But what’s the goal? And what are the constraints?

Does it make sense to have an additional piece of equipment? How much more does that cost in time and labor? Is it even possible to get a powered barge to the location?

It’s an off-label usage of the tool, but doctors write off-label prescriptions all the time. Just because a tool isn’t right in a standalone context, when you look at the bigger picture it can be.

Adding more isn’t always better

Posted on by
4

Earlier this year, I attended a pitch night at my local coworking space. One of the teams that presented is working on a product to help prevent driving while drowsy. It’s a noble goal — drowsy driving can be as dangerous as drunk driving. Like drunk driving, people aren’t very good at self-evaluating their fitness to drive when they’re sleepy.

But as they talked, I sat there going “no. What are you doing?” They talked about learning who the driver is and establishing a baseline of their attentiveness to measure their drowsiness. All kinds of cool whiz-bang stuff. And maybe someday they’ll add some haptic feedback to the steering wheel.

I suggested that they target diabetics as a first market. Hypoglycemia is dangerous, too, and it’s an easily-defined audience, which helps in initial go-to-market efforts. When I talked to them after their presentation, they started talking about maybe adding blood sugar sensors.

No. Just no. I asked them if they’d considered what storing data might mean. It creates a liability for the driver in case of an accident. It could be used by insurance companies to change rates. It could be compromised and used for something else.

Using the latest tech is neat, but only when it makes sense. And sometimes, the more you add, the worse things get.

If you want a diverse community, you have to stand up for marginalized members

Posted on by
Reply

On Monday, The Perl Conference’s Standards of Conduct Committee published an incident report. In a talk at the conference, a speaker deadnamed and misgendered a member of the community. As a result, they took down the YouTube video of that talk.

The speaker in question happens to be a keynote speaker at PerlCon. The PerlCon organizers wrote a pretty awful post (that they have since edited) that essentially dismissed the concerns of the transgender members of the Perl community. They went on to mock the pain that deadnaming causes.

I did not think to save their post in the Wayback Machine before they edited it down to a brief and meaningless statement. “We are preparing a great conference and do not want to break the festival and trash our year-long hard work we did for preparing the confernece, the program and the entertainment program.”

What they don’t say is “we value the marginalized members of our community.” And they make that very clear. Editing out the insulting part of their post does not ,mean much, as VM Brasseur pointed out.

If you value an inclusive community, you have to stand up for the marginalized members when they are excluded. If you don’t, you make it very clear that you’re only giving lip service to the idea. As it is, the PerlCon organizers don’t even apologize. They’re more concerned about the bad publicity than the bad effect on the community.